9- HDMI half done!

The above picture WAS NOT made by photoshop! Yesterday night my HDMI design displayed not only a red screen but a green and color patterned screen as well!

In this post I will describe the structure of my HDMI transmitter, the outcome of my testing and finally the features that it’s lacking.

Here is the list of modules that bring this device to life:

1- Encoder:

This module is the heart of the HDMI. It receives video data, Audio/Auxiliary data and two control signals. Moreover, it receives an audio enable signal which is active during data island and a video enable signal that is active during video island. The encoder encodes each form of the three using the right encoding algorithm and generates guard band patterns. Three encoder modules are used in my devices each for one color channel.

2- Slowbyhalf:

it doesn’t actually slow by half instead it divides the 10 bits coming out from each channel to a stream of 2 5 bits with the least significant five bits going out first. This device is necessary because the OSERDES can only serialize a maximum of 8 parallel bits.

3- Encoder_top:

The three Encoder modules are instantiated here. This module handles the wishbone communication with the processor. Moreover, it multiplexes the data coming from the wishbone bus to the correct register in each of the three channels. All wishbone signals are utilized in the standard way except the address bits are not used to point to actual registers but transmit the audio and video enable signals.

4- HDMItx:

This module contains along with the Encoder_top all the instantiation for Xilinx’s hardened devices in the FPGA that can’t be inferred by HDL coding. This includes:

• PLL device which is used for generating the clocks I need in my device.
• BUFPLL which is a specially designed buffer to transmit the clocks from the PLL to the OSERDES and sync them together.
• OSERDES which is used to serialize the output.
• BUFDS which creates the TMDS differential pair.

Apart from the above files I have a dummy master that I use to send the test patterns. Checking this device can be very helpful in understanding what my device expects from the processor.

Testing

I have tested the device with displaying a red, green and a test pattern.All the test patterns are in 640×480 resolution with 8 bits of color depth and 60 Hz frame rate. (25Mpixels to be precise)

The monitor can detect that there is a HDMI transmitter connected to it but it takes long time to sync with it and display the data and in some cases I need to reset my device several times. This can be either because od having a mistake in my timing or because I am not sending AVI info frames. I only send null packets for my data islands. Considering that my timing was found to be right during simulation the second reason is more likely to be the cause for the slow sync with the monitor. Further testing is required to confirm this assumption.

Another issue with the displayed test patterns is that even though it was supposed to be 480p vertically it stretched all across the screen which is originally intended for 1080p.

At the moment, the HDMI transmitter can handle any screen resolution and frame refresh rate as long as the correct clocks are provided by the PLL device. However, it can only handle 8 bit color depth and it’s not capable of handling resolutions that require the pixels to be repeated like the 720(1440)x480i resolution. Finally it only supports the basic HDMI functionality of having 4 TMDS channels.

The following improvements are required for the current HDMI transmitter:

1. Add parameters that can determine the clocks required to be generated by the PLL based on the intended resolution.
2. Add the circuitry required to handle color depth less than or more than 8 bits.
3. Handle resolutions that require repeating the pixels.
4. Test the performance for various screen resolutions.
5. Add other HDMI features like EDID, CEC and HDCP signals.