Yesterday probably I worked the longest (10 hrs maybe). I was trying to check whether the reason for slow fps is blocks after jpeg core. To check this I removed the the signals which the usb controller gave to the jpeg core. Also I wrote a code which counts the done signal of the jpeg core and I output the range of the count using LEDs(like for count less than 10 LED0 would light up). And it turns out that count of the done signal was in same range as the output fps. I tried different combinations like different encoding quality, allowing some signals of usb controller to control the jpeg core while ignoring other and the result was more or less the same. Meanwhile the code threw a timing error which took me 2 hrs to debug.
Also I did some reading on quantisation tables for JPEG. Turns out that quantisation should be low for luminance table (quality-85%) and high for chrominance of around 50%. But this is a general rule and cannot be used for all applications.
Today I plan to change the jpeg top module and see whether it improves fps. I have few ideas.
Also I did some reading on quantisation tables for JPEG. Turns out that quantisation should be low for luminance table (quality-85%) and high for chrominance of around 50%. But this is a general rule and cannot be used for all applications.
Today I plan to change the jpeg top module and see whether it improves fps. I have few ideas.
There are two other parts which might be useful for getting output.
ReplyDeleteThere is a USB-UART (the second micro USB port) which acts like a serial port as far as the FPGA is concerned, you could echo the counts out on that.
There is also the 8 segment display.
Could you commit the changes you made above to a temporary branch and push the changes into your own github repo fork. That way other people can evaluate your approach and offer suggestions.