Clocking of HDMI2USB

Today I spent almost my whole day trying to understand the clocking of the HDMI2USB. Well it turned out to be a tedious deal because the firmware is in VHDL spanning arcoss multiple files and it has a memory interface which is generated using the MIG tool. THe MIG tool is very poorly documented. Thanks to a blog post by Joelw (http://www.joelw.id.au/FPGA/XilinxMIGTutorial) things got slightly easier. So basically, the oscillator output (100Mhz) is connected to the memory interface which has a PLL and this PLL generates 6 clocks. The first 2 clocks are used by MSB and the rest are for user fabric. The PLL parameter used in HDMI2SB is same as given in the blog. So except the image buffer which is the DDR2RAM, rest of the blocks of HDMI2usb run on 78.125 Mhz clock.
But something that caught my attention was this line from the blog

wire c3_clk0; // 32 MHz clock generated by PLL. Actually, this should be 78 MHz! Investigate this.

c3_clk0 is the clock driving rest of the HDMI2USB blocks. If it really working at 32 MHz then we actually know our problem.

HDMI2USB is currently working at 15fps for 720p. The JPEG encoder in simulation works at 20fps for a clock of 100MHz and the image resolution being 1080p. So it should work at ~50fps for 720p images @100Mhz. So if the JPEG encoder is made to run at 32Mhz clock, frame rate will be 16fps.
So if the PLL output is actually 32Mhz as written by Joelw then we know what our problem is. If PLL output is 78 MHz then I can't say what the problem is. It might be that the problem is not with JPEG core but something else. Anyways I have pinged Joelw about this and waiting for his opinion. Tomorrow I will try investigating this. Let's see how it turns up.