Leonardo Piga

To start the development of Theora Hardware, I used a profiling tool called gprof to analyze Theora library version alpha 6, running on a x86 platform. This analysis showed me which functions should be implemented in hardware, due to the effort spent by the software on them. I chose Reconstruct, LoopFilter, and their related functions because they accounted for up to 70\% of all decoding time. Most of them have had their behavior completely implemented in hardware. The exception is ReconRefFrames, which is divided in two parts. I chose to keep one part in software because of the lack of data processing in the initial part. This part of ReconRefFrames just makes some decisions about which parameters might be forwarded to the hardware.

Beginning with ReconRefFrames, all modules were synthesized and completely tested on FPGA. Altera Stratix II EP2S60F672C5ES was used. The hardware was synthesized and connected to a NIOS II processor using an Avalon Bus. Theora IP acted as a NIOS II peripheric and could be accessed by a software running on this processor. The operation frequency was 50MHz and the software corresponded to a customized Theora library in which the functions converted to hardware were replaced by calls to the IP core.

Currently, Theora Hardware Decoder is able to decode videos of 96x80 pixels and all modules execute sequentially. In other words, the software does the pre processing and sends its parameters to the hardware. When this process finishes, the CopyRecon, LoopFilter and UpdateUMV modules execute. Note that the processor is idle, waiting the hardware. When the hardware finishes its job, it transfers the decoded frame to a VGA controller. It sends a signal to the software notifying it has already decoded the frame. At that time, hardware starts waiting the software and so on. I have plans to speed up the decoding process and make the decoder handles higher resolutions by making hardware work in parallel with software.

More about the project can be found here.