[theora-dev] Next step of Hardware Theora

Wed May 9 15:06:21 PDT 2007

Hi Andre,

I have the same opinion as Ralph:

To port the current implementation to an Open Source Processor is the
highest priority.
I know that it was my fault and I had to have done it already on my
Summer Of Code work, but is a quite complicated work and I didnt have
time to complete it additionally to the VHDL modules that I did.

I think that it should be the perfect work for you to do on your
Summer Of Code project.
You can ask for help to the professor Rodolfo, he knows a lot about
the LEON processor and have some students doing research work
related/using this processor.

See the others comments below

On 5/9/07, André Costa <andre.lnc at gmail.com> wrote:
> Hello,
>
> First of all, I would like to say that my work that I wrote in the other
> email would be to do in hardware the functions: CopyRecon, LoopFilter and
> UpdateUMVBorder. These are modules that Leonardo had made, but it wasn't ok
> in FPGA. When I had a chat with Leonardo we were thinking in rewrite these
> module for to do this running in FPGA (to debug in a Hardware level is much
> more difficult, sometime is faster rewrite the code). But, Leonardo
> discovered the mistakes on ExpandBlock and in the integration of modules in
> FPGA. The result is that all these modules are running in FPGA and don't
> need to be rewrite.
>
> Current State of Theora Hardware
> http://www.students.ic.unicamp.br/~ra031198/current.JPG
>
> Well, now I need to change the line of my project on GSoC. I wrote some of
> tasks that are necessary to have a Hardward implementation of Theora.
>
> 1 - Integration with a processor (Nios vs Leon)
> http://www.students.ic.unicamp.br/~ra031198/integration_processor.JPG
> We will need to compile the initial part of Theora in a processor and after
> to do a integration with the Hardware modules. For this, we will need to
> choose the processor. Stratix II (FPGA Altera) have a good support to NIOS.
> The alternative of a nonproprietary processor could be the LEON, but I think
> it maybe demand pretty much work to do run.
>
> 2 - To do a SDRAM controller.
> http://www.students.ic.unicamp.br/~ra031198/sdram_controller.JPG
> I think it is most important of all the tasks, because the current theora
> hardware can just have a maximum resolution of 280x210. I don't how much
> hard it will be to do this. Tomorrow I will have a chat with a professor
> from my university in order to discuss it.

This is much more complicated than port the code to the LEON processor.
An SDRAM is quite tricky to use and a fully operational SDRAM
controller can be as hard to design as the work that we already have
done for the Theora decoder.

But to have an Open Source VHDL implementation of an SDRAM controller
could be really great.
Looking on the www.opencores.org you will see that there is no open
source SDRAM controller like this.

It should be the next priority after the LEON.

>
> 3 - To do a video controller.
> http://www.students.ic.unicamp.br/~ra031198/video_controller.JPG
> This will be a module after the UpdateUMVBorder (function in Hardware). It
> will be the "player", the module in hardware that will put the images on
> video. I will talk with Leonardo, because it seems that He want to do this
> module.

I am quite sure that this task is simple. This part of the project
will be done by Leonardo.
I am already talking to Leonardo and some other students from UFCG (a
Brazilian Federal University).
There is Isaac and Wilson that worked with the MPEG4 decoder and they
did the video controller.
They will help Leonardo with this task.

>
> 4 - To finish the ReconRefFrames and to do other function that is before
> ReconRefFrames (could be the UnPackVideo).
> http://www.students.ic.unicamp.br/~ra031198/reconrefframes1_unpackvideo.JPG
> The code that is before the ExpandBlock() in the ReconRefFrames isn't in
> Hardware. I could to this part in Hardware and maybe to do also the
> UnPackVideo.
> The problem with UnPackVideo is because has a lot decison (if's and else's),
> I think it better to do in a processor.
> What do the function dsp_save_fpu() do? (it is betweet the UnPackVideo and
> ReconRefFrames)
>
> 5 - To put the current Hardware Theora of old for new VP3 codebase.
>
> Timothy told me about the old and new VP3 codebase, but I am a little
> confused.
> I read the vp3-format.txt and I saw that theora/doc/vp3- format.txt
> theora-old/doc/vp3-format.txt are the same file.
> In don't know If i am understanding something wrong. In the specification of
> Theora, I saw the "VP3 Compatibility", but this shows the differences
> between original VP3 and the Theora Specification. What are differences
> between new and old VP3 codebase that timothy said to me? is there any
> document that shows the differences?
> Felipe Portavales and Leonardo Piga used the libtheora-1.0alpha6 in the
> reference model of Hardware Theora. is libtheora-1.0alpha6 using the new or
> old codebase?
>
>
> So, I thinks the most important task is the SDRAM controller, but the
> Integration with a processor and video controller are also important. What
> do you think that would be nice to me to do in the SOC?

All those tasks are important, but in my opinion the priority order should be:

1 - Integration with a processor (Leon)
2 - To do a video controller. (Leonardo will do it)
3 - To do a SDRAM controller.
4 - Future works:
     - To finish the ReconRefFrames and to do other function that is before
     - To put the current Hardware Theora of old for new VP3 codebase.

>
> Timothy, if you prefer, tomorrow i will enter on IRC and we can discuss
> this.
>
> Thanks,
>
> André Costa
>
> --
> André Costa
> Gerente Técnico
> Projeto BrazilIP
> LSC IC-UNICAMP
>
>  Cel: + 55 13 9201 1870
> http://www.brazilip.org.br/
> _______________________________________________
> theora-dev mailing list
> theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
>

-- 
________________________________________
Felipe Portavales Goldstein <portavales at gmail>
Undergraduate Student - IC-UNICAMP
Computer Systems Laboratory
http://www.students.ic.unicamp.br/~ra023772/