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.

Can you clarify the part about registering rgb on slow fpga?I think this might be the issue

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.

So I just need to make another register supposed redf,bluef,greenf and assign the red,blue,green values just below the posedge clock block ending and before the endmodule?

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.

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.

It is less glitchy than before I can see the image but it seems to be moving not static.It is glitchy still.Also it seems to be moving and blinking if that's what you mean

Um - addr_cnt[12:0] is enough for 8000 pixels, 640×480 is - more. The GIF looks sync failing.

I am displaying an image of 80x80 size not the full 640x480

Can you explain about sync failing and how do I resolve it?

Can it be that the sync is failing due to delay from BRAM?

I have attached my bram part

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

I am a complete newbie so I am facing difficulties in understanding most of the things. So I need to reset my address where?I am confused about this

Got it vlad I didn't know about the frame concept, I managed to get it right

I managed to get it right If that is get whatever picture I want displayed rather than now addresses start at zero for each frame, you are welcome to answer your own question - this is a Q&A site, essential information shall be accessible without drilling down longish comment chains.

@greybeard,I am sorry if my post breaks the rules of this site.In the future I will be more careful in debugging the code and not make these silly questions

I don't think any of your post breaks rules here. Well-asked questions deserve useful answers: You can answer your own question, possibly helping others, possibly gaining "reputation".