FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6448 Discussions

Static RGB values using Intel HDMI IP does not appear on video sink monitor

Evan44
Novice
919 Views

I can't seem to get hardwired static RGB values inside an Intel HDMI IP reference design to appear on the video sink. 

I start off with the HDMI IP reference design configured for simple video pass thru, and I am able to demonstrate this using a Cyclone 10 GX DevKit + HDMI 2.0 DCard, with the video source (laptop) plugged into DCard RX Conn, video sink (monitor) plugged into DCard TX Conn. 

Next, I hardwire the RGB values inside the hdmi_rx_top.v module after the symbol alignment where its RGB output---concatenated across wide bus accommodating 2 symbols*10bits*3chans---is fed into the HDMI RX module, where it outputs its video into RXTX module, which loops it back into HDMI TX module, and finally transmitted to video sink. I am able to confirm this modification  post-synthesis through the RTL viewer. 

I have tried all types of value combinations through iterative compilations but none seem to work. The fact that the video pass thru does not work either at least tells me I am looking in the right place to do this.

I feel I am missing something simple that is preventing this simple hardwire from working. Thanks in advance for any insight on this issue.  

Labels (1)
0 Kudos
1 Solution
Evan44
Novice
847 Views

UPDATE: I was finally successful in hardwiring a static RGB color within the Intel HDMI reference design architecture and getting that color to appear on the sink monitor. 

To do this, instead of hardwiring the RGB pattern into the hdmi_rx_top module where the parallel aligned RGB data is output from the aligner and feeds the hdmi_rx module, I went inside the rxtx_link.v and hardwired the video data feeding in from the HDMI RX core (hdmi_tx_data).

I was able to surmise the 16-bit RGB bit allocations. At two symbols per clock, the 96-bit bus contained two 48-bit color combos, where each 48 bits was comprised of 16 red, 16 green, 16 blue.

A pure blue pattern was created by assigning the value 0x00000000FFFF twice in this vector, and once the FPGA was loaded and after all the HDMI-related initializations, the blue appeared in the entire sink monitor screen.

 

I do not know yet why trying to hardwire the RGB pattern onto the aligned 10-bit RGB vectors feeding the HDMI RX core would cause the RX PLL to not lock.

I am new to this type of HDMI/video FPGA development, so this was just a "walk before run" endeavor. I hope in time it will make more sense. 

View solution in original post

0 Kudos
4 Replies
Evan44
Novice
875 Views

More testing insight:

I placed a 2:1 mux in the RGB path, with one input driven by the original video pass RGBs, the other input driven by the hardwired RGB values, and the mux select is driven by a very long duty cycle timer bit (3 seconds duty cycle).

The lab result is that the sink monitor shows the video pass thru (from video source laptop) for 3 seconds, followed by a blank screen for 3 seconds, and then repeats. The RX PLL LOCK LED goes on for 3 seconds during the video pass thru, then turns off during the blank screen. 

Apparently during static RGB video transfer, the associated PLLs do not lock, preventing the static color from appearing on the sink monitor. Is this a scrambling issue? Does the locking of the PLL require some transitions on the RGBs?

0 Kudos
ZiYing_Intel
Employee
860 Views

Hi Evan44,


Would you mind to share the .qar file? So that I can debug the issue from my side.


Best regards,

Zi Ying


0 Kudos
Evan44
Novice
848 Views

UPDATE: I was finally successful in hardwiring a static RGB color within the Intel HDMI reference design architecture and getting that color to appear on the sink monitor. 

To do this, instead of hardwiring the RGB pattern into the hdmi_rx_top module where the parallel aligned RGB data is output from the aligner and feeds the hdmi_rx module, I went inside the rxtx_link.v and hardwired the video data feeding in from the HDMI RX core (hdmi_tx_data).

I was able to surmise the 16-bit RGB bit allocations. At two symbols per clock, the 96-bit bus contained two 48-bit color combos, where each 48 bits was comprised of 16 red, 16 green, 16 blue.

A pure blue pattern was created by assigning the value 0x00000000FFFF twice in this vector, and once the FPGA was loaded and after all the HDMI-related initializations, the blue appeared in the entire sink monitor screen.

 

I do not know yet why trying to hardwire the RGB pattern onto the aligned 10-bit RGB vectors feeding the HDMI RX core would cause the RX PLL to not lock.

I am new to this type of HDMI/video FPGA development, so this was just a "walk before run" endeavor. I hope in time it will make more sense. 

0 Kudos
ZiYing_Intel
Employee
796 Views

Hi,


Glad to hear you that your issue has been resolved.

Since your issue has been resolved, I am now close the case.

If you have any question after the case closed, please do feel free to submit another issue.


Best regards,

Zi Ying


0 Kudos
Reply