TMDS Part 1

As discussed in the previous section. In digital video, the pixel and audio data are transmitted down wires at extremely high data rates (720p needs 74.25 million pixels per second transferred). Each pixel is comprised of 24 bits in modern digital video, with 8 going to the red color channel, 8 going to the green, and 8 going to the blue. In almost all modern digital formats, these three color channels each get their own digital channel to work in parallel. However that still means that each digital color channel needs to transfer 74.25 million \times 8 = 594 million bits per second. That’s a lot of 1’s and 0’s to be transmitted on just one wire. Unfortunately sending a lot of 1’s and 0’s means transitioning the voltage on the line at >100MHz or GHz rates, which means the wires can be giving off tons of electrical noise which can be extremely detrimental to the whole process (red pixel info interferes blue pixel info).

In order to at least partially mitigate high frequency value transitions, HDMI (High-Definition Multimedia Interface) encodes its data using a scheme known as Transmission Minimized Differential Signaling (TMDS). In this scheme, the number of 1 \to 0 or 0 \to 1 transitions in a portion of data is reduced at the expense of sending slightly more bits overall. Specifically, TMDS will take every 8 bits of data and transform it into 10 bits for sending.

The first extra bit added deals with minimizing transitions in the line by either doing an XOR- or XNOR-based encoding scheme (the "TM" part of our TMDS). The second extra bit deals with keeping the average number of 1's and 0's on the line at about equal to remove any DC voltage that may build up which is problematic when doing differential signaling (the "DS" part of our TMDS).

Because this is a kinda complicated thing to think about and is needed very often, the HDMI specification provides an encoding algorithm for the task. We reproduce the appropriate page(s) below which shows the algorithm and its key:

Even with this at our disposal, how it works isn't readily understood or explained. So let's take each part on its own. First we need to minimize transitions in our bytes. Then we adjust our value to keep the running tally of 1's and 0's about even.

Let's first think about how to minimize transitions. This part is taken care of in the first decision of the algorithm:

The strategy of the first part of TMDS is to take an input byte X with bits \{x_7, x_6, x_5,x_4, x_3,x_2, x_1, x_0\} and generate a processed output byte Y with bits \{y_7, y_6,y_5,y_4,y_3,y_2,y_1,y_0\} from one of two options:

1. Option One:
   • The original lsb is assigned to the lsb of the new data frame: y_0=x_0
   • The remaining 7 output bits are the XOR of two bits as expressed: y_n= x_n \oplus y_{n-1} for 7 \geq n \geq 1 where n is the bit number (note \oplus is one way of writing the Exclusive OR operation).
2. Option Two:
   • The original lsb is assigned to the lsb of the new data frame: y_0=x_0
   • The remaining 7 output bits are the XNOR of two bits as expressed y_n= \overline{x_n \oplus y_{n-1}} for 7 \geq n \geq 1 where n is the bit number. (note the bar overtop implies logical negation of the content contained within. Similar to ~(x && y))
3. Following this, the final decision, Y becomes the option with fewer internal transitions. If Option 1 is chosen, append a 1 as the ninth bit else, append a 0 as the ninth bit.
4. Finally, send all 9 bits to the next stage.

Now you can do things this way (generate both options and then compare them), however this would be wasteful. Since there are only 256 different bytes to send, when the designers came up with this encoding scheme they noticed some patterns and did a little math and found out you can just do the two checks listed in the flow-chart diagram above:

• If the sum of 1's in the byte is > 4 OR if it is 4 and you have a 0 in the lsb, choose option 2, else choose option 1. This might seem weird, but damnit, it actually works.

Consider the number: 8b1111_1110.

• If you were to encode it using option 1 you'd get '9b1_1010_1010.
• If you instead do option 2 you'd get: '9b0_0000_0000

The algorithm told us we should have chosen Option 2 (since it has seven 1's in it), and looking at the two options, it sure looks like Option 2 has fewer bit transitions.

Then consider the number: 8b0000_0001. This has one 1, so we should choose option 1...is that the right choice?

• If you were to encode it using option 1 you'd get '9b1_1111_1111. Minimal transitions
• Meanwhile option two is a disgusting '9b0_0101_0101. Lots of transitions! Yuck!

You can try this on any number and it will pick the better of the two options.

On the receiving side, the system receives packet Z with bits \{z_8,z_7,z_6,z_5,z_4,z_3,z_2,z_1,z_0\} and builds up a decoded byte W with bits \{w_7,w_6,w_5,w_4,w_3,w_2,w_1,w_0 \} using the following process:

1. Use the ninth bit to determine if the data was XOR or XNOR processed
2. If XOR:
   • The received lsb is assigned to the lsb of the new data frame: w_0=z_0
   • The remaining 7 output bits are the XOR of the preceding two input bits as expressed: w_n= z_n \oplus w_{n-1} for 7\geq n\geq 1 where n is the bit number
3. If XNOR:
   • The received lsb is assigned to the lsb of the new data frame: w_0=z_0
   • The remaining 7 output bits are the XNOR of the preceding two input bits as expressed: w_n= \overline{z_n \oplus w_{n-1}} for 7\geq n\geq 1 where n is the bit number.

OK. So that's how that works. Your job now is to build a module that is combinational only and which carries out this first "choice" part of the TMDS algorithm. It should take in the 8 bits of data_in and then using the algorithm taken right out of the TMDS specification, it should generate the 9 bit qm_out.

The basic skeleton is shown below:

module tm_choice (
  input wire [7:0] data_in,
  output logic [8:0] qm_out
  );

endmodule

Code Skeleton
Select File  No file selected

Loading...