theora dev - Nov 2004 - FPGA implementation

Andrey Fillipov posted the following update at his sourceforge website on 
11/16/04.

"Coded and simulated the DC predictor module - hope the Theora description
I
used matches the actual codec :-)
 Also modified the modules released earlier to support non-coded blocks. For 
the DCT/IDCT I tried to reduce the power consuption by minimizing switching 
of the registers and counters when the output data goes to /dev/null."

That brought him up from 60% to 70% complete, and it looks like he is on 
schedule for a 12/14/04 target for 100% complete.
John

I believe I really am on schedule, design seems to fit in the FPGA both in
resources ( will use around 65-75%) and timing. For the coding itself I
will need just Huffman encoder for the fixed-width (12-bit)
"pre-tokens"
saved in the SDRAM buffer and to combine together old code for the image
acquisition, new 8-channel SDRAM controller I made earlier and the
"compressor_one" code.

Next thing - to balance registers among clock phases - too many switching
at the same time causes "ground bounce" and the chip malfunctioning
due to
the high level of "noise" on ground connections. There are currently 4
signal phases (90 degrees) available and I will need to distribute modules
among them.

In parallel I need to find out the actual power consumption of the FPGA
and if the selected DC-DC converter in the camera will be sufficient - the
power required will increase when I'll have all the code running. If that
test will fail I'll have to increase the PCB size to accommodate bigger
converter - that is the reason I'm holding the camera production until
I'll resolve that matter.

In any case the board modification is rather simple and it will take me
just several days, after that I'll make a first batch of 20 cameras so
some software development can start in parallel with me continuing working
on FPGA (there are always bugs there as in the software). I'll need some
tools for testing and troubleshooting the encoder - something like single
frame analysers where I can view the data on different stages of decoding
by the standard (and tested) algorithm. I'll probably need to write some
custom tools to analyse intermediate compression data that is/will be
available in the SDRAM

On Thursday 18 November 2004 02:57 pm, Andrey Filippov
wrote:
> I believe I really am on schedule, design seems to fit in the FPGA both in
> resources ( will use around 65-75%) and timing. For the coding itself ...
Wow. Thank you for that more detailed update, Andrey.

Some readers of this list might be interested to know that the FPGA  being 
used in the Elphel model 333 network camera is a "Xilinx Spartan 3 1000K 
gates" chip.

I think I saw a press release at the Xilinx web site dated about a year ago 
that mentioned the price of the Spartan 3 1000k FPGA to be $12.

There is a press release dated November 8, 2004 that announces the release of  
lower power FPGAs, the Spartan-3L family.  The 1000k gates member of this 
family has a price of less than $14.  Xilinx also mentions in this press 
release that they have "shipped over 100 million Spartan Series
devices."
http://www.xilinx.com/prs_rls/silicon_spart/04123s3lfamily.htm

That is mighty sweet.
John

> Yes, it becam obvious when I went to the next level of my manual parsing -
> decoding Theora packets.
Trying to reimplement "decoder" (capable of just filling COEFFS array)
I
found difference between the documentation and how theora-experimental
works (I did not hack main branch, but it shoul probably be the same as
the video is decoded). The only way I could make my decoder parse data
with the same result was when I noticed that regular decoder uses
different Huffman group calculation, so my program matched the results
only after the following chdnge.

//   HG=(ti>0)?((ti>4)?((ti>13)?((ti>26)?4:3):2):1):0;
     HG=(ti>0)?((ti>5)?((ti>14)?((ti>27)?4:3):2):1):0;

And I carefully checked that in my program ti=0 for DC, 1 - for AC1,...
ti=63 for the last AC63.

Could it be an error in the Theora_I_spec.pdf (page 95)?
Or am I missing something again?

Andrey

>>> Then I used the virtually unmodified headers from the original
file,
>>> cut
>> it where the actual frame data starts (I had to add one byte to the
>> lacing
>> numbers as my data was 0xe6a bytes long while the original - 2d2) and
>> recalculated the check sum for the last page.
>
> Correction - that was the total file size, frame is 0x35f
>
Sorry to bother - checksum was calculated over the wrong range :-)