09-28-2020 02:30 PM
I have built a HDMI receiver using GTH transceivers that is working great with most sources. I have run across a couple of sources that I see buffer over and underflows in the transceiver. I used the GTH transceiver wizard to build the HDMI interface using 3 GTH RX channels. I have a fixed reference clock. The buffer over/under flows occur on the transceivers not listed as the master in the transceiver wizard. I brought out the recovered clock (RXOUTCLKPMA) for each of the RX blocks. I measure, using a frequency counter, slightly different recovered clocks on each channel. A source that works has exactly the same frequency on the recovered clock for each channel and no over/under flows on the transceiver buffer.
Here is an example of the measured recovered clocks:
HDMI input channel 0: 74.24846 MHz
HDMI input channel 1: 74.24848 MHz
HDMI input channel 2: 74.24852 MHz
I believe the buffer over/under flows are caused by the read out clock from the master channel being slightly different from the other channels. I moved the master channel to a different channel and get the same result, over/under flows on the channels that are not the master.
It appears that the compatibility issue only occurs with a specific HDMI transmitter IC company. That HDMI source works fine with other monitors I have, just not with my implementation. I can't use the Xilinx HDMI implementation due to logic size and transceiver placement constraints.
Thanks for any suggestions!
09-29-2020 01:01 PM
Typically recovered frequencies are off in this manner when an RX reset is done before the RX input is present. Without a frequency stable input to the RX the clock data recovery circuit can't lock to the correct frequency. For this reason you can't do a reset all on a channel that is being looped back. The RX will be interrupted by the TX reset and often won't lock properly.
09-29-2020 04:04 PM
Thanks for the suggestion. In this case, I'm using an external HDMI transmitter (video switcher) that is supplying the HDMI signal. I did try to add in a manual rx PLL and datapath reset via a VIO connection to reset after the signal was stable, but the result is the same.