Electrical – Generating 1080p@30Hz from ADV7511

The thing is, once you go outside the spec, anything can happen (and usually does on a major customer demo!). You might get it to work, sort of, sometimes, but as soon as you break spec, you are responsible for whatever does not work reliably.

I am not at all surprised that some monitors work and some do not, IME it is usually the computer monitors that are fussy while tellies will often take any old rubbish.

There are about half a dozen or so sets of frame timings that pretty much everything accepts, basically the broadcast derived ones, but they tend to need that clock that you don't have, and yea, EDID is often best ignored (or at least taken with caution), buggy does not begin to describe some of them.

One gotcha is to check the sound, as the dividers to derive the 48K audio rate from the pixel clock will be off, and that may cause issues.

Time for a board respin?

Seems like a reasonable idea. However, the data will not enter the FPGA bit-serial, it will be deserialized and decoded in parallel; the FPGA fabric can't go fast enough to deal with bit-serial 1920x1080 HDMI. You'll need to decode the TMDS encoding in order to mess with the pixel data anyway. And you'll also have to re-encode and re-serialize the signal to send it out the door again. The data path should run on the order of one pixel per clock cycle, so you can trivially swap out colors as necessary. I would recommend using an indexed color configuration - one 2D array of small numbers, perhaps 3 or 4 bits, that indexes into an array of RGB values. One of the values could then correspond to 'passing through' the original color. Or you could combine colors by adding, or even use one bit as a 'mask' bit to select whether or not to consider the original color.