<a href="http://elphel.cvs.sourceforge.net/elphel/camera333/fpga/x333/">http://elphel.cvs.sourceforge.net/elphel/camera333/fpga/x333/</a> - you may find _working_ (for Theora) IDCT implementation in Verilog for Xilinx Spartan 3 there.
<br><br>Andrey<br><br><div><span class="gmail_quote">On 5/31/06, <b class="gmail_sendername">Felipe Portavales Goldstein</b> <<a href="mailto:portavales@gmail.com">portavales@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
YEAAAAAAAAHHHHH<br><br>IDCT_SLOW VHDL model is working<br>but I neet optimize it to consume less FPGA resources like multiplyers.<br><br>i will send to svn this night<br><br><br>On 5/31/06, Felipe Portavales Goldstein <
<a href="mailto:portavales@gmail.com">portavales@gmail.com</a>> wrote:<br>> On 5/31/06, Timothy B. Terriberry <<a href="mailto:tterribe@vt.edu">tterribe@vt.edu</a>> wrote:<br>> > Remembering to CC: the list this time.
<br>><br>> :-)<br>> my mistake<br>><br>> ><br>> > Felipe Portavales Goldstein wrote:<br>> > > On 5/31/06, Timothy B. Terriberry <<a href="mailto:tterribe@vt.edu">tterribe@vt.edu</a>> wrote:
<br>> > ><br>> > >> Felipe Portavales Goldstein wrote:<br>> > >> > My question is:<br>> > >> ><br>> > >> > The result of (_Gd + _Cd) can be a number with more than 16 bits ?
<br>> > >> > (yes, it can be because they are int32, but the algorithm could<br>> > >> > guarantee something about that... I dont know...)<br>> > >><br>> > >> With normal input, certainly this would never occur. However, due to
<br>> > >> quantization error, rounding error, etc., it is theoretically possible<br>> > >> to generate a number with more than 16 bits here.<br>> > ><br>> > ><br>> > > Good :-)
<br>> > ><br>> > >><br>> > >> > If can, the cast (ogg_int16_t) will truncate the number to the 16 less<br>> > >> > significant bits, and will get a wrong result...<br>> > >> >
<br>> > >> > the ip[0] is 32 bits, so, why truncate to 16 bits ?<br>> > >><br>> > >> The main answer is, "To make SIMD/hardware implementations easier."<br>> > >> These will generally use 16-bit registers, and so will automatically
<br>> > >> have done the truncation.<br>> > ><br>> > ><br>> > > Your right, Its better to use 16-bit registers. And using 16-bit<br>> > > adders and multipliers we can get shorters critical-paths , having a
<br>> > > higher clock rate.<br>> > ><br>> > > Then, I have other question:<br>> > ><br>> > > If the result is truncated to 16 bits, why the IntermediateData was<br>> > > declared as 32 bits ?
<br>> > ><br>> > > ogg_int32_t IntermediateData[64];<br>> > > ogg_int32_t * ip = IntermediateData;<br>> > ><br>> > > I think this is because the dequant_slow result is 32 bits, and is
<br>> > > stored in the IntermediateData<br>> > ><br>> > > But, this dequant result is multiplied by a 16 bit defined cossine<br>> > > factor , and this new result is shifted right 16 bits and stored in
<br>> > > IntermediateData<br>> > ><br>> > > Im thinking If I could use 16 bits IntermediateData array.<br>> > ><br>> > > The dequant especification says:<br>> > > Output parameters:
<br>> > > DQC - integer array - size = 14 bits<br>> > ><br>> > > I think that I can use the InteremediateData as 16 bits integer.<br>> > > What do you think ?<br>> ><br>> > Yes, you certainly can. On modern 32-bit CPUs, 16-bit instructions are
<br>> > very, very slow, so we avoid them when we can. The only real reason to<br>> > use 16-bit operands on a 32-bit CPU is to save memory bandwidth, which<br>> > is the primary bottleneck in video processing. Since IntermediateData is
<br>> > local, and likely to be entirely in cache, there's no reason to make it<br>> > 16 bits.<br>> ><br>> > If you are implementing the iDCT for a different instruction<br>> > set/architecture, I highly suggest working from Section
7.9.3 of the<br>> > spec directly. The spec can be obtained from:<br>> > <a href="http://www.theora.org/doc/Theora_I_spec.pdf">http://www.theora.org/doc/Theora_I_spec.pdf</a><br>><br>> I'm working on a theora decoder on FPGA. I'm writing directly the
<br>> hardware in VHDL.<br>><br>> I'm preparing to put the VHDL files on the SVN and post in this list a<br>> description of this work as soon as possible.<br>><br>> Yes, I'm reading the spec.<br>> But sometimes the libtheora software can help.
<br>><br>><br>> ><br>> > >> The important thing is not that the iDCT gives you valid values that<br>> > >> make sense in such situations, but that it gives you the _same_ values<br>> > >> across all implementations, even when the input is invalid. If that were
<br>> > >> not the case, then the decoded frame would not be the same as what the<br>> > >> encoder _thought_ the decoded frame was going to be, and so the next<br>> > >> subsequent frame would also be wrong, etc., all the way until the next
<br>> > >> keyframe.<br>> > >><br>> > >> Think of it this way: you can never generate a _wrong_ result so long as<br>> > >> you follow the specification. The specification tells you what result
<br>> > >> you're going to get for any input. If the encoder chose an input that<br>> > >> caused overflow, well, that's the encoder's problem, not the decoder's.<br>> > >><br>> > >> > But I'm realy confused with the >> 0 ,
<br>> > >> > This shift right zero can do something or someone just forgot to delete<br>> > >> > it ?<br>> > >><br>> > >> I assume the original author was playing around with dividing up the >>4
<br>> > >> in the op[] stage between the two. It doesn't matter; any compiler worth<br>> > >> its salt will optimize the useless operation away.<br>> ><br>><br>><br>> --<br>> ________________________________________
<br>> Felipe Portavales <<a href="mailto:portavales@gmail.com">portavales@gmail.com</a>><br>> Undergraduate Student - IC-UNICAMP<br>> Computer Systems Laboratory<br>> <a href="http://www.lsc.ic.unicamp.br">
http://www.lsc.ic.unicamp.br</a><br>><br><br><br>--<br>________________________________________<br>Felipe Portavales <<a href="mailto:portavales@gmail.com">portavales@gmail.com</a>><br>Undergraduate Student - IC-UNICAMP
<br>Computer Systems Laboratory<br><a href="http://www.lsc.ic.unicamp.br">http://www.lsc.ic.unicamp.br</a><br>_______________________________________________<br>Theora-dev mailing list<br><a href="mailto:Theora-dev@xiph.org">
Theora-dev@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/theora-dev">http://lists.xiph.org/mailman/listinfo/theora-dev</a><br></blockquote></div><br>