HDMI passthrough on Digilent Atlys - timing issues?

[NiHaoMike]

I started playing with my Digilent Atlys board some more to continue learning Verilog and FPGAs. I decided to try the HDMI examples found here:
https://joelw.id.au/FPGA/DigilentAtlysResources
The pattern generator pretty much just worked when I loaded the code, but the HDMI passthrough behaves strangely.

Signal source: Raspberry Pi programmed to output 720p, ignoring EDID.
Display devices used for testing: Viewsonic monitor, Brookstone pocket projector, Seiki 4K monitor.
Other HDMI devices tried in setup: Two different HDMI splitters, LG wireless HDMI kit, LKV373A HDMI over Ethernet kit.

Results: when routing signal through FPGA, only the Brookstone and the Seiki are able to receive the signal and do so without any glitches. The Viewsonic switches the LED to active but does not display an image. The LG and LKV373A simply stay at "no signal". The splitters do pass through the signal without changing the behavior of the devices connected to them - e.g. if the Brookstone and the Viewsonic are connected, each behaves as if they're directly connected to the FPGA. In all cases, if the FPGA is taken out and replaced with a passive coupler, everything works as expected.

Any ideas how to debug it?

[hamster_nz]

Is the Pi generating HXMI or DVI-D? I bet it is HDMI.

The FPGA is expecting DVI-D, so the HDMI data islands are causing breaks in the Hsync Vsync pulses on the output.

Easiest debbug is to dump the EDID on the Pi and see if the FPGA is wanting DVI-D only.

[NiHaoMike]

What would be the simplest way to make the design compatible with HDMI?

[hamster_nz]

Try setting hdmi_drive in your config file to force DVI-D... see https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

If that works then you know what the problem is.

Full HDMI RX, decode, recode and TX is a bigish project unless you use IP blocks.

 

[NiHaoMike]

That was it! I would have liked a solution that doesn't involve reconfiguring the source, but my first "real" project with HDMI and FPGA is likely going to be an implementation of Chip's Challenge or a similar game without a CPU - just some state machines. I plan to start with the game board implemented as a multi port memory and the HDMI output code converting it to images in real time. Then I implement different parts of the game logic that work by iterating over the memory, likely tying it to the vsync so it doesn't glitch due to objects moving in the middle of a frame.

I also wonder if it's better to not use the DDR at first and get to it if/when I have to or just get it working (with an existing library) in the beginning and take advantage of it right away.

[hamster_nz]

That was it! I would have liked a solution that doesn't involve reconfiguring the source,

If you wanted to attempt to make something to allow it to process HDMI signals.

(this will only work for 24-bpp, 444 RGB, full range modes, which has the same signal timing and channel colour encoding as 24-bpp DVI-D)

1. The 'data islands' are inserted in the SYNC periods. You can see these are coming in the data stream because of a guard band (a special preamble). When in the 'data island' only sixteen different bytes are sent to represent four bits on each channel. One of the three channels carries the HSYNC and VSYNC signals, so you will need to decode this channel to recover the HSYNC and VSYNC. You have to do this (rather than streching the current SYNC values over the data island) because if VSYNC changes state while in a data island it will not be seen, and the monitor will fall out of sync at what looks to be random times.

2. The active video pixels are prefixed with a different guard band to the data islands, and this needs to be stripped and replaced with SYNC periods.

With both of these done the resulting signal / coding will be identical to DVI-D 

Have a look for the "HDMI specification filetype:pdj" on Google to find the full documentation you will need (e.g. guard band and TERC4 byte values)

I also wonder if it's better to not use the DDR at first and get to it if/when I have to or just get it working (with an existing library) in the beginning and take advantage of it right away.

Don't - wait until you are a bit more skilled. DDR has latency that you need to solve, complicating the design quite a bit. (you need to read ahead and hold data in a FIFO that can never be allowed to empty out)

[hamster_nz]

Oh, one other option would be to ignore the incoming HSYNC & VSYNC inputs, filter the data stream based on the video guard band (so you only have data for active pixels, and a valid_data signal) then add new HSYNC & VSYNC signals using a couple of counters that sync with the pixel data stream.

The problem with this is you have to know the video timing values for the SYNC pulses in advance (however these are pretty well standardized now).

[NiHaoMike]

I started modifying the pattern generator to display the game board and noted that it uses a chain of 2 DCMs and a PLL to derive the clock for the HDMI logic. Is there a reason for it like phase noise filtering or would it be OK to simplify it?

[hamster_nz]

I started modifying the pattern generator to display the game board and noted that it uses a chain of 2 DCMs and a PLL to derive the clock for the HDMI logic. Is there a reason for it like phase noise filtering or would it be OK to simplify it?

You could try fixing it. But without looking at it I think you find:

The first PLL/DCM generates the pixel clock, using 'weird' mult/divide ratios from the system clock

The second PLL/DCM generates the high speed clocks needed for the SERDES system, and is switched between the test pattern's clock and the incoming HDMI clock.

It may also be that it might be for physical clocking resources - e.g. maybe the SERDES I/O clock has to be generated by a specific clocking region.

However, you might be correct and somebody has bolted two IP blocks together, and ended up with twice the clocking resources used than needed.