Vlad

Your address arithmetic is all over the place. You didn't even reset pixel address at the beginning of each frame.

If the picture is static (i.e. nothing moves or blinking) then it's not glitchy in HDL sense. It's just wrong logic being implemented. At least it's clear the address arithmetic is off. The address of the pixel to be read from bram is incremented more times per screen line than there are pixels in the image row. The image width is 80, and the relevant section in your code increments addr_cnt on the range [383; 463] which is 81 pixel.

Yes. But only if that is the real problem you're observing. The photo in the question would help in trying to understand what's actually wrong.

Imagine your RGB is the output of some multiplexer doing palette stuff. The inputs to the multiplexer are not all settle simultaneously, so during short period after the pixel clock edge the output of the multiplexer will change multiple times reflecting the continuing changes on the multiplexer inputs. The duration of this transition depends on the fpga speed grade. To avoid leaking the glitchy transitions to RGB outputs you just save the color values after the multiplexer in the registers, so with each pixel clock edge the monitor will only see final value, clean from fluctuations.

At those speeds, and assuming the timing analyzer did not report any violations - this should not be the reason for major issues. PLL would be preferable when you need better jitter, or when divided clock fails your timings. Otherwise VGA is pretty forgiving. You'd more likely to see the glitches between the pixels if you didn't register the r/g/b outputs on some slow fpga.

Does "core rope memory" counts?: en.wikipedia.org/wiki/Core_rope_memory