Forum Discussion
Static RGB values using Intel HDMI IP does not appear on video sink monitor
- 3 years ago
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.
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?