Tmds Receiver

[Patrizia Leones]

Iam interested in measuring audio latency of an HDMI sink device (DUT). I have an 8K Murideo Seven Generator, but I believe that its audio latency measurements may be off by 15 or 20 ms, so I would like to verify these.

I can easily generate a low-bandwidth HDMI signal with large back porch and embed a short audio pattern using a desktop computer. I expect that, without the TMDS encoding, I should be able to see the audio pattern within an oscilloscope capture of this large back porch. In fact, I've used an old analog oscilloscope and found that the voltage pattern on TMDS 2 and 3 pins visibly change on the oscilloscope display when audio is played... But I do not currently have a storage scope and I expect the TMDS encoding will make it too difficult to know exactly when the change is happening and ending.

To address this, I would like to know if there is a simple TMDS decoder IC that would take in a twisted pair TMDS and output a non-TMDS digital signal that I can record with an oscilloscope. Or, maybe there is some sort of TMDS decoder device that exists. I am having a hard time finding the correct internet search terms for what I am looking for.

I understand that it is more common to use an HDMI receiver for this purpose, but an HDMI receiver does quite a bit more than I would like and is much more complicated (?) to wire up than I imagine a simple decoder IC for a single set of TMDS pins. In fact, if I used an HDMI receiver, it would not give me access to the data islands that contain the audio packets, but instead would regenerate the audio clock and audio signal, introducing audio latency... which is the exact thing that I would like to measure, so avoiding this audio extraction behaviour is necessary.

The closest thing I have found so far is the "capture" mode of tools like the Teledyne LeCroy quantumdata 980 Protocol Analyzer. I believe this would give me access to time stamped audio packets inside of the data islands. Unfortunately, I don't believe that this tool has an additional analog/trigger input that I can use to record or trigger on the DUT audio output like an oscilloscope would.

Transition-minimized differential signaling (TMDS) is a technology for transmitting high-speed serial data used by the DVI[1] and HDMI video interfaces, as well as by other digital communication interfaces.

The transmitter incorporates an advanced coding algorithm which reduces electromagnetic interference over copper cables and enables robust clock recovery at the receiver to achieve high skew tolerance for driving longer cables as well as shorter low-cost cables.

The method is a form of 8b/10b encoding but using a code-set that differs from the original IBM form. A two-stage process converts an input of 8 bits into a 10 bit code with particular desirable properties. In the first stage, the first bit is untransformed and each subsequent bit is either XOR or XNOR transformed against the previous bit. The encoder chooses between XOR and XNOR by determining which will result in the fewest transitions; the ninth bit encodes which operation was used. In the second stage, the first eight bits are optionally inverted to even out the balance of ones and zeros and therefore the sustained average DC level; the tenth bit encodes whether this inversion took place.

The 10-bit TMDS symbol can represent either an 8-bit data value during normal data transmission, or 2 bits of control signals during screen blanking. Of the 1,024 possible combinations of the 10 transmitted bits:

Control data is encoded using the values in the table below. Control data characters are designed to have a large number (7) of transitions to help the receiver synchronize its clock with the transmitter clock.

On Channel 0 the C0 and C1 bits encode the Horizontal synchronization (HSync) and Vertical synchronization (VSync) signals. On the other channels they encode the CTL0 through CTL3 signals which are unused by DVI but in the case of HDMI are used as a preamble indicating the type of data about to be transferred (Video Data or Data Island), the HDCP status and so on.

TMDS is similar to low-voltage differential signaling (LVDS) in that it uses differential signaling to reduce electromagnetic interference (EMI) which allows faster signal transfers with increased accuracy. TMDS also uses a twisted pair for noise reduction, rather than coaxial cable that is conventional for carrying video signals. Like LVDS, the data is transmitted serially over the data link. When transmitting video data and used in HDMI, three TMDS twisted pairs are used to transfer video data. Each of the three links corresponds to a different RGB component.

The physical layer for TMDS is current mode logic (CML),[2] DC coupled and terminated to 3.3 Volts. While the data is DC balanced (by the encoding algorithm), DC coupling is part of the specification. TMDS can be switched or repeated by any method applicable to CML signals. However, if DC coupling to the transmitter is not preserved, some transmitters' "monitor detection" features may not work properly.

I am considering purchasing a Nexys Video dev board soon, but I have noticed the HDMI port is not connected to the GTP ports on the FPGA, just the standard IO ports. So I am wondering, can this board do 1080p 60fps with 24-bit RGB colour?

HDMI uses the TMDS standard and the Nexus Video does a good job implementing it. The mDP ports however do use two GTP transceivers per port. The Genesys2 is even better with 4 GTX transceivers per mDP port. Both boards are good platforms for video projects. You are correct about the Artix clocking limitations. The Kintex on the Genesys2 does better. Even the Spartan6 on the ATLYS board does better.... though Series7 devices have superior clocking than Spartan 6.

You'll have to do you due diligence to determine what platform is best for your video needs. An alternative to the Nexys Video is the Numato Labs Mimas-A7 which is also an Artix board but with a smaller part than the Nexys Video A100T. I've used all of these for successful project development.

The IO banks on the Nexys Video and Genesys2 boards for the HDMI ports use Vccio = 3.3V so, even if the board design allowed for LVDS ( they don't) the Diligent boards can't so LVDS. It's complicated.. so do your homework if you have certain video requirements to meet.

The Genesys2 is even better with 4 GTX transceivers per mDP port. Both boards are good platforms for video projects. You are correct about the Artix clocking limitations. The Kintex on the Genesys2 does better.

Genysys 2 look great, but is about double the cost and if I am not mistaken the Kintex requires a Vivado licence which I believe is included for 1 year with the Genysis 2, but then requires to be paid for, so not really an option for me due to the cost.

An alternative to the Nexys Video is the Numato Labs Mimas-A7 which is also an Artix board but with a smaller part than the Nexys Video A100T. I've used all of these for successful project development.

I have just had a look at that, seems like a nice little board (website says it uses the A50T though), but I think the Nexys video still offers me more flexibility due to having the A200T, as they both have 160-pin breakout headers, of which about half (think just over half on the Nexys Video to be honest) can be used for GPIO.

For my project I have considered (at least to begin with) I could implement it using a HDMI transmitter like the ADV7513 via a breakout board through the FMC connector on the Nexys Video, then come back later and try to eliminate the ADV7513 and implement it directly on the FPGA (hence these questions).

I understand that, the only reason I mentioned LVDS is just because that is what the Xilinx datasheet refers to when discussing performance characteristics. According the the datasheet, the -1 speed grade (as is used on the Nexys video I believe) has a max transmitter / receiver speed of just 950 Mbps.

As a side note, my project is going to be taking in 24-bit RGB from an external device and outputting over HDMI. As I have mentioned above, I have looked at just using an ADV7513 to transmit the HDMI and get round this. However, seemingly Digilent have found a way to make it work, and I am trying to understand how have they done it?

I don't think that Digilent has any published information that warrants a particular video standard or color depth for the Nexys Video HDMI capabilities. I don't know of an FPGA board vendor who isn't happy to sell stuff to people who make poor assumptions... that's just the nature of the industry.

There is more to this than just hardware. Can you write own video IP or do you need to use free, or purchased, IP? Free IP tends to come and go with FPGA vendor tool versions. For certain applications where they think that then can monetize the IP assume that free IP that supports your specific needs isn't available. As you point out, the Kintex requires a license to create a bitstream. For the Genesys2, Digilent provides a voucher for a license that will be tied to one development host. This is a permanent license that lasts as long as your development PC host. The 1 year term refers to the tools versions updates that will honor that license. While not perfect, it's better than what other FPGA vendors will offer. BTW, my recent Kintex 325T license that came with the Genesys2 also is usable for the NetFPGA-1G-CML board using the same device but in a different package. And it works with ISE 14.7. I have a similar node-locked license for a different FPGA device that Xilinx let me transfer the license to a different PC; that was a couple of years ago. Unfortunately, the tools that I use on the new platform don't support this particular, Xilinx branded, board the ZCU106... which is quite disappointing considering the cost of this board.. and the fact that I bought it from Xilinx. Disappointing, but not surprising to anyone who'd been doing FPGA development for a while.

3a8082e126