Reprogrammable DisplayPort firmware-EEWORLD

Collect

DisplayPort is becoming increasingly popular in the computer industry. It is a royalty-free digital display interface standard that is a potential replacement for analog VGA. As more and more computers begin to support DisplayPort, the demand for DisplayPort interfaces is growing for monitors, TVs, projectors, and all other peripherals that have DVI, HDMI, LVDS, or VGA interfaces.

Most existing DVI and HDMI interfaces are designed with level-shifting circuits specifically for dual-mode DisplayPort sources. However, dual-channel DVI, LVDS, and VGA interfaces all require protocol conversion. For example, for a VGA interface, the video signal must be converted from a high-speed digital signal to a low-speed analog signal, which makes the VGA interface a very complex device. Typically, a firmware engine in the protocol conversion DisplayPort interface manages this conversion.

The role of firmware in protocol conversion DisplayPort interfaces

Firmware is the engine in the chip that drives the protocol conversion. Several important tasks depend on the state machine implemented by the firmware. When the cable interface is plugged into the signal source, only after several important steps can the video be successfully transmitted to the "receiver" (or receiver) and displayed correctly. The firmware is in charge of the following things:

Communication with the signal source is established through a signal called HPD (Hot Plug Detect) and a sideband channel called AUX CH (Alternate Channel);

Complete link training;

In actual transmission, monitor errors in the main link;

Read EDID information from the receiver and pass it to the signal source;

Convert HPD information and return it to the signal source;

The DisplayPort source has its own state machine internally for talking to the sink. The cable interface firmware must correctly interact with the source to ensure proper operation. The state diagram shown in Figure 1 is for link training as recommended in the DisplayPort 1.1a specification. Note that all firmware guidelines given in the specification are recommendations only and are not necessarily the only way to implement or achieve the functionality. Different vendors providing image sources will implement these details in their own way, which can cause interoperability issues.

Figure 1 Link training state machine recommended in DisplayPort 1.1a specification

Current industry challenges

The DisplayPort specification is fairly new and evolving. Each GPU that supports DisplayPort may have a different DisplayPort source implementation, which means that a protocol-converting DisplayPort interface may work fine when plugged into GPU1, but it may not work for GPU2 due to GPU2's DisplayPort implementation. For example, GPU2 may access the interface's internal registers in a different order than GPU1, or GPU2 may need some specific data that GPU1 does not before the GPU outputs video.

This situation illustrates the edge case of the difference between specification conformance and device interoperability, and is common in the early stages of new standards adoption. This problem will decrease over time as the knowledge accumulated in interoperability testing helps standards bodies introduce new conformance tests.

Another uncertainty is the variability in the operation of the large number of different legacy monitors and display panels currently in use. Therefore, an interface that works well with one monitor may not work with another, even if the same computer is transmitting data via DisplayPort. To date, there are no definitive tests or design requirements currently in effect that can ensure 100% interoperability of interfaces.

Let's consider a few cases where interoperability problems arise due to differences in implementation.

Several cases

Case 1: Figure 1 shows a link training sequence recommended by the DisplayPort 1.1a specification. The link training sequence consists of two phases: clock recovery phase and symbol lock phase. The recommended training sequence requires entering the symbol lock phase after the clock recovery phase is successful.

We have encountered cases where the signal source does not follow this recommendation. In this case, after successfully completing the clock recovery phase, the signal source initiates another clock recovery phase. The result may be a link training failure because the interface may make different assumptions about the working sequence of the signal source. To overcome this interoperability problem:

1. The specification can be more specific, stating and/or prescribing a specific way of training the sequence, which may require months of negotiation within the standards body to reach agreement on the specification.

2. A compliance test can be added, which will take several months to implement.

3. A practical and effective way is to overcome this difference through small changes in the interface firmware. The simplest practical way is to enhance the firmware of the interface.

Case 2: When a monitor at the other end of a protocol-converting DisplayPort interface is connected or disconnected, the DisplayPort specification requires that the interface should send an interrupt back to the signal source. We have found that some DisplayPort source drivers expect the interface to de-assert the HPD signal instead of generating an interrupt, so the VGA interface will not work properly when used with such a source.

The solution to this problem is to either upgrade the signal source driver or replace the firmware in the interface to adapt to the behavior of the signal source. In March 2010, NXP published a survey of a large number of product implementations on the market. The survey found that two of the four interface solutions tested could not handle the interface correctly, and according to the DisplayPort specification, most DisplayPort signal sources could not give a correct response to the display disconnection/connection process.

To this end, VESA has added compliance testing to check for non-compliance with this specific display detection problem for protocol conversion type interfaces. Adjusting the firmware in the interface is a practical solution.

Case 3: Some DPCD registers are reserved for future use, and new DP sources/drivers may access these registers at some point. Therefore, the firmware may need to be upgraded. For example, the following registers are reserved for different purposes:

00090h- 000FFh, 00109h- 001FFh: Reserved

0x247, 00249h – 0025Fh, 00262h – 0026Fh: Reserved for test automation expansion

00280h - 002FF: Reserved

0x303 0x5FF: Reserved for specific usage of the source device

0x403 0x5FF: Reserved for specific usage of the receiving device

0x503 0x5FF: Reserved for vendor-specific usage of branch devices

0x601 0x6ff: Reserved register

0x700h 0x67fff: Reserved register

Programmability provides a convenient solution

One solution to all of these issues is the flexibility of the firmware inside the protocol-converting DisplayPort interface.

Most DisplayPort to VGA interface solutions available in the market today implement a certain firmware either by using ROM or by converting the certain firmware into hardware. A notable exception is the NXP PTN3392, which has an integrated flash memory inside that can be reprogrammed online with new firmware. It does not require any additional hardware and programming is done through the AUX channel of DisplayPort (as shown in Figure 2). All 3 of the case studies mentioned above can be solved/supported by this device. This approach solves the interoperability issues that arise in this field, simplifies the work of interface manufacturers, and provides a seamless experience for the end customer.