HDMI/MHL Protocol Testing Using HDMI/MHL Protocol Analyzer Suit

Introduction HDMI is a digital replacement for existing analog video standards. Termed as the catalyst for the DTV revolution. This is driving HDMI standard to support increase in data speed to higher video resolutions to emerging needs . As a result, Design and validation engineers need tools to improve efficiency by performing a wide range of standards-required tests quickly and reliably.

This application note describes HDMI/MHL Protocol Analyzer that addresses Protocol testing and validation needs , the challenges faced while testing complex HDMI digital Interface and how oscilloscope-resident test software , provides powerful debug while testing compliance protocol Ctest and unprecedented automation to perform a wide range of tests .

HDMI /MHL protocol overview:

HDMI: High Definition Multimedia Interface, a compact uncompressed digital video and audio

interface. HDMI system architecture is defined to consist of Sources and Sinks. A given device may have one or more HDMI inputs and one or more HDMI outputs. Each HDMI input on these devices shall follow all of the rules for an HDMI Sink and each HDMI output shall follow all of the rules for an HDMI Source.

HDMI cable and connectors carry four differential pairs that make up the TMDS data and clock channels. These channels are used to carry video, audio and auxiliary data. In addition, HDMI carries a VESA DDC channel. The DDC is used for configuration and status exchange between a single Source and a single Sink. The optional CEC protocol provides high-level control functions between all of the various audiovisual products in a user’s environment.

MHL: The Mobile High-definition Link is an interface for transmitting digital television audiovisual

signals from mobile phones, mobile video players, video cameras, still image cameras and other audiovisual sources to television sets, projectors, monitors and other video displays. The MHL interface is a low-pin-count high definition (HD) video interface based on the same Transition Minimized Differential Signaling (TMDS) technology used in the Digital Video Interface (DVI).

MHL can carry high quality multi-channel audio data and can carry all standard and high- definition consumer electronics video formats. Content protection technology is available.

MHL also carries control and status information in both directions. In addition, MHL has a dedicated pin to supply power from one MHL system to another.

Protocol Overview: The HDMI link operates in one of three modes: Video Data Period, Data Island

period, and Control period. During the Video Data Period, the active pixels of an active video line are transmitted. During the Data Island period, audio and auxiliary data are transmitted using a series of packets. The Control period is used when no video, audio, or auxiliary data needs to be transmitted.

Video Data Period: Video data periods are used to carry the pixels of an active video line. Each

Video Data Period is preceded by a Preamble, described above. Following the Preamble, the Video Data Period begins with a two character Video Leading Guard Band. There is no Trailing Guard Band for the Video Data Period. During active video periods, 24 bits of pixel data are encoded using TMDS transition minimized encoding during each TMDS clock period.

Data Island Period: During the Data Island period, audio and auxiliary data are transmitted using a

series of packets. This auxiliary data includes Info Frames and other data describing the active audio or video stream or describing the Source. Each Data Island is preceded by a Preamble, Following the Preamble, each Island starts with a Leading Guard Band. The first packet of the Data Island then follows. During every TMDS clock period of the Data Island, including the Guard Band, bits 0 and 1 of TMDS

Channel 0 transmit an encoded form of HSYNC and VSYNC. Bit 2 of TMDS Channel 0 is used to transmit the Packet Header. All four bits of TMDS Channels 1 and 2 are used for the Packet data. Each packet is 32 pixels long and is protected by BCH ECC for error correction and detection purposes.

During the Data Island, each of the three TMDS channels transmits a series of 10-bit characters encoded from a 4-bit input word, using TMDS Error Reduction Coding (TERC4). TERC4 significantly reduces the error rate on the link by choosing only 10-bit codes with high inherent error avoidance.

Control Period: The Control period is used when no video, audio, or auxiliary data needs to be transmitted. A Control Period is required between any two periods that are not Control Periods.

Control Period is used for transmission of the Preamble. The Sink for character synchronization also uses the Control Period.

During Control Periods, 2 bits per channel, or 6 bits total are encoded per TMDS clock using a transition maximized encoding. These 6 bits are HSYNC, VSYNC, CTL0, CTL1, CTL2 and CTL3. Near the end of every Control Period, a Preamble, using the CTLx bits, indicates whether the next Data Period is a Video Data Period or a Data Island Period.

Preamble: Immediately preceding each Video Data Period or Data Island Period is the Preamble. This is a sequence of eight identical Control characters that indicate whether the upcoming data period is a Video Data Period or is a Data Island. The values of CTL0, CTL1, CTL2, and CTL3 indicate the type of data period that follows. The remaining Control signals, HSYNC and VSYNC, may vary during this sequence.

Challenges Validating HDMI/MHL Interface:

In todays Digital world considerable amount of time is dedicated by the big Semiconductors leaders in validating their SOC products on their end product.As the Mobile technology growing rapidly, therefore the time to market this product shirks. Therefore the major challenge faced by todays SOC designer and Validation engineers is to validate their High speed Serial interface like HDMI/MHL, eMMC /SD and SDIO within short window of validation phase

In Validation phase major amount of quality time of Validation engineer is spent in validating the High Speed protocol manually which in turn reduces the efficiency and time or by using the expensive solution available in the market like protocol analyzer which in fact comes with no much flexibility in handling the Physical and protocol layer challenges, also along with other drawbacks and dependency. Some of the drawbacks and challenges faced by the Validation engineers while validating the interface are listed below:

There is no single tool/ Instrument to handle physical and Protocol layer challenges Difficult to correlate the data from Protocol to Physical layer Increasing the complexity of the test system due to multiple equipment. Need to learn new equipment for each problem. There is no device to see the complete frame as shown in the specification

List of HDMI/MHL Compliance Tests:

Source Protocol [HDMI/MHL] • Legal Codes  • Basic Protocol• Extended Control Period• Packet Types

Source Video [HDMI/MHL]• Pixel Encoding• Video Format Timing• Pixel Repetition• AVI Info Frame

Source Audio [HDMI/MHL]• IEC 60958/IEC 61937• ACR• Audio Sample Packet Jitter• Audio Info Frame• Audio Sample Packet Layout

Source Interoperability with DVI • Interoperability with DVI

Source Advanced Features • Deep Color• Gamut Metadata Transmission• High Bitrate Audio• One Bit Audio• 3D Video Format Timing• 4K x 2K Video Format Timing* -

Limited support• Extended Colorimetry Transmission* Limited support due to present Oscilloscope 250M Record length per channel. Complete support is expected in next generation Oscilloscope. Note: Up to 200MHz clock rate is supported for all the resolution.

Source Protocol: Here in this phase of test, different Mode and different feature supported by the source is tested. The HDMI source needs to go through this test inorder to adhere to the HDMI protocol.

Legal Codes: Verify that Source only outputs legal 10-bit codes. Verify that, for all pixels within the analysis period, the Source DUT transmits only 10-bit values on each of the three TMDS channels that correspond to one of the following:

Legal Video Data codes. 4 Control Period codes 16 TERC4 codes Data Island Guard Band (all 4 possible values for Channel 0) Video Guard Band

Basic Protocol: Verify that the Data Island and Video Data periods are preceded by the preamble, Verify the sequence of preamble are intact indicating the upcoming data period is a Video Period or is a Data Island. Verify that Source only outputs code sequences for Control Periods, Data Island Periods and Video Data Periods corresponding to basic HDMI protocol rules.

Extended Control Period: Verify that Source outputs an Extended Control Period within the required time window that is Maximum time between Extended control Periods 50msec, Minimum duration between Extended Control Period 32Tpixel. This is done starting with the first pixel of the capture; perform the search for each 50millsec of capture.

Packet Types: Verify that Source only transmits permitted Packet Types and that reserved fields are zero. Verify if the packet types:

Null Packet Type ACR Packet Type Audio Sample Packet Type General Control Packet Type Source Video

Source Video: Here in the Phase of test the source is tested for the different encoding scheme that is been supported. Also verify that all specified video line pixel counts and video field line counts (both active and total) and HSYNC and VSYNC positions, polarities, and duration shall be adhered to when transmitting a specified video format timing.

Pixel Encoding: Verify that the all HDMI Sources shall support either YCBCR 4:2:2 or YCBCR 4:4:4 pixel encoding whenever that device is capable of transmitting a color-difference color space across any other component analog or digital video interface. Verify that an AVI InfoFrame is transmitted on every video field. Examine video output and all AVI InfoFrame transmitted from Source.

Video Formatting Timing: Verify From beginning of capture data, scan for first Video Data Period in capture. Verify all the specified video line pixel counts and video field line counts (both active and total) and HSYNC and VSYNC positions and durations shall be adhered to when transmitting a specified video format timing. Verify If pixel clock is within or outside of allowable range, Examine VSYNC/HSYNC relationship for two video fields. Determine 861B Video Code for the transmitted format. Note for subsequent tests.

Pixel Repetition: Verify that Source DUT indicates Pixel Repetition values in the AVI as required and that the pixels are actually repeated the indicated number of times. These verifications assume that the Video Format Timing test has been executed and passed for the transmitted format and that the 861B Video Code has been determined.

AVI InfoFrame: Once the source determines that the sink supports the AVI InfoFrame, Verify source will send this information to the DTV monitor once per frame . Verify that with every Video filed an AVI infoframe is transmitted when required and that any AVI infoframe transmitted is accurate. AVI InfoFrame must be transmitted once per field whenever Source supports the transmission of the AVI InfoFrame. AVI shall be sent when Source is transmitting any video format timing listed in EDID with multiple aspect ratios. The information like Active Format Aspect Ratio, bar widths, over/under scan, non uniform picture scaling and etc., the information that can be made used by the sink device, if this information is present at the source device and valid .

Source Audio: Tests shall be performed at each of the following three combinations of video and audio formats. One of the Source-supported mandatory video formats (480p, 576p or 640x480p) and an audio format with the highest Audio Sample packet rate available. Here in this phase of test, Audio data being carried across the HDMI link. Test to verify the Audio Clock Regeneration circuit and parameters. Verify the audio feature supported by the source and sink.

IEC 60958/IEC 61937: To verify that the audio sample carried by the each Audio Sample Subpackets follows the specification defined by the IEC 60958 or IEC61937

Checks for the no of sample present within the Audio Sample Subpackets. Layout 0 can carry up to 4 samples from a single IEC 61937 or from a single 2- channel IEC 60958 stream of audio. Layout 1 can be used to carry one audio sample with three to eight channels of L-PCM audio

ACR: Audio data being carried across the HDMI link, which is driven by a TMDS clock running at a rate

corresponding to the video pixel rate. The technique of recreation of the clock at the sink is called ACR. The ACR protocol test is used to verify the relationship between the two clocks parameters in the ACR mechanism I.e. TMDS Clk and Audio Sampling clk. Verify the N and CTS parameter value.

Audio Sample Packet Jitter: Verify that the source audio packet jitter is within the limits

specified. If audio packet jitter relative to actual sampling rate does not exceed one video horizontal line period plus a single audio sample period then PASS else FAIL

Audio InfoFrame: Verifies the digital audio supported by the sink. Verify that Source transmits an

Audio InfoFrame whenever required and that contents are valid. If the source and supports the device supports the transmission of the Audio InfoFrame and (i.e., the DTV Monitor has included CEA Extension Version 3 in EDID) and digital audio, then the Audio InfoFrame, will be sent once per VSYNC period along the digital audio is being sent across the interface. Setting the Data Byte 1 through 3 sets correctly does this. The data applies to the audio associated with the next full frame of video data. If the source device is sending multi-channel uncompressed audio, then it shall also send valid speaker channel allocation information and down-mix information in Data Bytes 4 & 5 of this InfoFrame.

Audio identification information in Data Bytes 1-3 may be useful in identifying audio. if the DTV and the source device support more than “basic audio,” as defined by the physical/link specification, then this information shall be sent and shall accurately identify the stream while digital audio is being sent. If the source sends the basic audio, it is not required to send this information.

Audio Sample Packet Layout: Verify the Layout type used by the source to transmit the audio

information is valid. Verify that the if source and sink devices support audio format more than basic audio, than this information is sent using the audio identification information to the sink.

Source Interoperability with DVI: Verify that all HDMI Sources shall be compatible with DVI 1.0 compliant sink devices (i.e. “monitors” or “displays”) through the use of a passive cable converter. Likewise, all HDMI Sinks shall be compatible with DVI 1.0 compliant sources (i.e. “systems” or “hosts”) through the use of a similar cable converter.

Interoperability with DVI: All HDMI Sources and Sink shall be compatible with DVI 1.0

compliant sink and source devices (i.e. “monitors” or “displays”) through the use of a passive cable converter. this requires that the Source/Sink operate under the following limitations:

Video pixel encoding shall be RGB. No Video Guard Bands shall be used. No Data Islands shall be transmitted.

Source Advanced Features:Deep Color: Source and Sink each time when in deep color mode captures the packing phase and

color depth of the last pixel character of a Video Data Period. The General Control Packet (GCP) is used by the source occasionally to communicating the current color depth and the packing phase of the last pixel character sent prior to the GCP. The GCP data is valid whenever CD (CD0, CD1, CD2, CD3) is non- zero. Whenever the Sink receives a GCP with non-zero CD data, it should compare the receiver’s own color depth and phase with the CD data. If they do not match, the Sink should adjust its color depth and/or phase to match the CD data. Source only communicates with GCP, sink which supports deep color mode/color depth. Source while operating in Deep color mode will communicates with the sink with GCP with non zero value, CD values which indicates the color depth and packing phase of the last pixel character sent prior to the GCP. Once a Source sends a GCP with non-zero CD to a sink, it should continue sending GCPs with non-zero CD at least once per video field even if reverting to 24-bit color, as long as the Sink continues to support Deep Color.

If the Sink does not receive a GCP with non-zero CD for more than 4 consecutive video fields, it should exit deep color mode (revert to 24-bit color).

HDMI/MHL Validation Test Setup:

HDMI Test Setup consists of DUT (Tablet/Smartphone) which is configured by the Host to run the stress full Video content @different resolution on the HDTV via HDMI/MHL interface . The HDMI test fixture is used to capture and display the HDMI/MHL signal from the HDMI/MHL connector onto the scope , Here the HDMI PA SW is run inorder to carry out the Protocol test on this valid HDMI/MHL signal displayed on the scope .

MHL/HDMI Protocol Analysis Software:

The industry’s first Oscilloscope based TEK-PGY-MHL/HDMI Protocol Analysis software lets you see every event in the MHL/HDMI stream from MHL/HDMI frame to physical layer analog signals which conventional protocol analyzer can not show.

TEK-PGY-MHL/HDMI Protocol Analyzer software performs the MHL/HDMI protocol compliance tests as per MHL CTS 2.0 and HDMI CTS 1.4a. It provides unmatched flexibility in analyzing, debugging, and correlating the test results from MHL/HDMI Frame to physical layer analog waveforms to address the MHL/HDMI design challenges.

For efficient debugging, TEK-PGY-MHL/HDMI software provides unique multi viewer which comprises of frame summary viewer, frame viewer, bus viewer, Protocol viewer, Data Island viewer and Event and test results viewer. Automatic cross-linking between all these viewers enables you to see and correlate the data in different parts of the MHL/HDMI protocol stack

TEK-PGY-MHL/HDMI protocol analysis software along with Tektronix physical layer compliance test solutions and Industry leading Tektronix high performance oscilloscope offers a single box solution for physical and protocol layer testing.

HDMI Front Panel:

Select Panel to set the application: o Select :Its use to select the Mode, required displays and Compliance Tests

(i.e. HDMI/MHL).o Configure: To set the signal source:

wfm format , P/A/V binary files , oscilloscope To set the Video format:

Encoding: RGB, YCbCr (4:4:4) or YCbCr(4:4:2) Bits /Pixel: 24bit, 30bit,36bit or 48bit

To set the Audio: SamplingFrequency:48Khz,32Khz,44.1Khz,88.2Khz,96Khz ,192

Khz

o View: To Validate the signal and connections o Capture: To set Total duration of capture, Frame display, test and Oscilloscope setup

assistant . Client Panel: Used to configure the Test mode, Displays and lists of test Changes.

Mode: Configure it to carry out protocol test on HDMI/MHLDisplays: Configure the display in order to analyze the HDMI/MHL protocol for better understanding if we come across any test that have failed ,with the flexibility of viewing the signal in different view , we can root cause the problem easily .

Execution Panel: Used to Run, Analyze export and Report the results• Run to capture and analyze the signals from Oscilloscope based on the configuration set in

selection panel• Analyze to view the test results and detailed view• Export to export the analyzed results in different formats• Reports to generate the reports in html format.

Once all the parameters have been configured based on the user specification and needs, than the protocol analyzer is ready to trigger the protocol test either on HDMI/MHL.it will carry out the selected list of protocol test on the input and does the background processing on the input signal fed in the form of Image. This test processing may last for few sec to few minutes based on the list of test configured and selected.

Once the list of test have been executed successfully, than the user can analyze the status on the complete list of selected test by using the analyze window.

if the analyze windows notifies that all the list of selected protocol test have been passed successfully than the user can either import this test summary in HTML format or can navigate through the different view in order to understand the working of each test and its implementation .

if the user come across any such test which have been notified as failed on the analyzer window .than the user can navigate through the event viewer and summarize the each activity on each failed or passed tests .

Here is event viewer user can select the failed test and walk over all the activity carried out while executing that particular failed test in order to get some leads to debug the issues. Once the user gets some data about the nature of the failure than the user can navigate through the detail view like Data Packet Viewer, Frame Viewer, Protocol Viewer and Bus Viewer, In order to root cause the issues.

• Frame summary view – Helps to quickly locate the frames with error for detailed analysis

• Bus Viewer– Shows the Bus activity along with the H Sync and V Sync.

• Frame Viewer– Complete frame view with image and horizontal and vertical blanking periods.

• Event Viewer– Shows the test status and details of test.

• Data Packet Viewer

– Details about the Data Island period• Protocol Viewer

– Lists the protocol information in tabular format.

In Data Packet viewer user gets flexibility of navigating through all the data packets in the selected frame.o Lists Line number, Pixel number, message number with respect to frame, type of data

Island and Decoded Values.

User gets to analyze each packet in the frame and analyze it manually .o Provides the description of all the data packets.o Provides the raw data packet information.o Ability to filter one or more data packet type.o Clicking the data Island packet links the corresponding area in bus viewer,

Frame viewer and Protocol Viewer

If the user suspects the protocol implementation and if the failure is due to data transaction on either one of the 3 TMDS channel not adhering to the protocol, than the user can verify the failure by navigate through the protocol viewer and analyze each data on the TMDS channel is adhering to the protocol .

Provides tabular view of the protocol listing. Lists the message type, 10 bit data value, corresponding decoded values.

Data Island - > TERC4 Control Period -> Control Encoding Active Video Period -> TMDS

By clicking the entry in the table links the bus viewer, image viewer.

If the any test fails the user can relocate the information about the frame which has projected the test has failure. Than the user can analyze the frame in different modes by the color coded Data island period , Control period and Video island period .it helps quickly to relocate the error frame and the frame that need to be discarded .

User is provided with the flexibility of thumbnail for identifying the image errors. It provides quick Pass/Fail/Discard indication for the quick error frame identification. By clicking a pixel in the frame view, the corresponding pixel in bus view and protocol view will be zoomed and highlighted for cross correlating

Mouse move over the frame image shows the following information

– Video period: Transmitted 10 bit and 8 TMDS decoded value– Control period: transmitted 10 bits converted 2 bit control– Data Island Period: Transmitted 10 bit and decoded TERC4 – Line number, pixel number, number of video guard bands, number of data island guard

band pixel.– Image pixel index.– By clicking a pixel in the frame view, the corresponding pixel in bus view and protocol

view will be zoomed and highlighted for cross correlating.User in Bus View has the flexibility of viewing the physical layer waveform, shows the color coded control period , Data Island Period and active video pixel. If user suspects the failure due to the skew between the channels , than the user can also capture the Clk to Data or Data to Clk skew for the Debug purpose .

• Displays the MHL/HDMI transmission in bus diagram. • Shows the multiplexed MHL data and de-multiplexed logical channels as per the specification.• For MHL Data +Ve and Data –Ve signals, the common mode clock and data is shown.• Utility functions such as Zoom, Un-zoom, Pan, Un-do, Fit vertical, Fit horizontal, Fit complete

screen and show waveform helps to move over the bus diagram.

X Axis provides frame pixel index, line index, line pixel index for quick pixel identification

Summary: Industry First Oscilloscope based HDMI/ MHL Protocol Analyzer provides superior debugging capabilities. HDMI/ MHL Protocol Analyzer provides In-depth visibility from HDMI/ MHL Frame to Physical Layer signals which no other protocol Analyzer can provide. Cross linking between Frame Summary Viewer, Frame Viewer, Bus Diagram Viewer, Event Viewer, Data Island Packet Viewer provides more flexibility in debugging Physical Layer and Protocol Layer Problems One single box solution for debugging Physical and Protocol Layer Oscilloscope can be used for Physical Layer and Protocol Layer Testing Provide more Return On Your Investment on your Oscilloscope. Reduces your test system complexity by reducing the requirement of dedicated Protocol Analyzer and Logic Analyzer. Reduces the cost of the test system.

About Prodigy Technovations Pvt Ltd Prodigy Technovations Pvt Ltd (www.prodigytechno.com) is a leading global technology provider of Protocol Decode, and Physical layer testing solutions on test and measurement equipment. The company's ongoing efforts include successful implementation of innovative and comprehensive protocol decode and physical Layer testing solutions that span the serial data, telecommunications, automotive, and defense electronics sectors worldwide.

Other products HDMI and MHL Protocol Compliance Test Software MIPI UniPRO and LLI Protocol Decode Software MIPI UFS Protocol Decode Software HSI Electrical Validation and Protocol Decode Software I2C Electrical validation and Protocol Decode Software SPI Electrical Validation and Protocol Decode Software I2S Electrical, Audio, and Protocol Testing Software UART/RS232 Protocol Decode Solution FlexRay Protocol and SI Analysis Software USB2.0 Protocol Decode Software HSIC Protocol Decode Software