As it turns out, the JPEG encoder works at 78 MHz. As I didn't have a oscilloscope, I wrote a VHDL code too check the frequency of the PLL using LED. And yes, it turned out to be greater that 70 Mhz. So my theory that the core is running slow because the clock is slow turns out to be false. I did run smartexplorer to remove see if I can remove the timing faliure but it didn't. Further analysis revealed that I can safely ignore the path that was failing timing constraint as it was the PLL MUX selecting signal which was not important. I used a TIG in the UCF file to remove it. I changed PLL parameters to make the encoder run at 100 MHz, and strangely ISE did not throw any timing violation but things didn't work on hardware. I will try once again in the weekend. I use guvcviewer to check the frame rate of the video streaming and it comes out to be 12 fps on average. I will study other parts of HDMI2USB and try to find the bottleneck.