Talk:Porting Theora to 353 cameras

From ElphelWiki
Revision as of 02:13, 6 March 2008 by JeremViewsurf (talk | contribs)
Jump to: navigation, search

Ok, I started a new page on the Theora project in 353 cameras. I started with a global approach and a list of modules that need to be changed or replaced on the 353 model. Feel free to correct me or add suggestions as I'm not (yet...) an expert on Elphel cameras. I think the first step is to make an exhaustive list of the hardware blocks that need modifications and then detail what need to be done in each block. --JeremViewsurf 03:48, 19 February 2008 (CST)


As I understand your first need is not a streaming but producing a small video clip to be uploaded via FTP. This can be done more easy with minimal non FPGA modifications.

We will probably create a CVS branch for your port, to be able to test it we need to compile a standard 7.1.x firmware disabling everything sensor or FPGA related and change the FPGA bitstream. --Alexandre.Poltorak 07:53, 19 February 2008 (CST)


You mean that it should be possible that the system can handle software Ogg Theora encoding for a non real-time application such as producing small video clips ? I'm aware that it depends on the output resolution, framerate and length of the clip but does a 1 min 1024x768 @ 25fps clip for example can be processed in a reasonable delay ? I'll discuss with Viewsurf's development team in order to obtain more precise specs concerning video output (in terms of length, resolution, framerate and encoding delay acceptable) but if you can give me an idea of what the software part can handle, I would consider spending more time in soft Theora transcoding instead of FPGA design. --JeremViewsurf 03:37, 20 February 2008 (CST)


No, sorry i was not speaking of transcoding. It would take too much calculation power and is not possible on the camera's CPU. The Theora encoding should be done in FPGA. What i was speaking about is the software part.. I think you do not need a streamer for the first steps. You only need to generate a clip in the FPGA memory, and upload it to a FTP. --Alexandre.Poltorak 08:32, 20 February 2008 (CST)


Some questions concerning changes in the FPGA :

  • Is it necessary to keep histogram and timestamp blocks in a design which supports Theora only ?
    • I believe the camera will be rather crippled w/o those features--Andrey.filippov 10:24, 25 February 2008 (CST)
  • Is it possible to keep channel 0, 1 and 3 design without changes in the memory controller ?
    • Theora implementation used different (more advanced) memory controller that the JPEG, it was getting 95% efficiency at Theora data structure, so you need Theora memory controller. But if you mean by "Channel 0 design" the gamma tables and histograms - yes, they probably could be ported (with some changes, of course). As for channels 1 and 3 - similar are available in Theora 333 also--Andrey.filippov 10:24, 25 February 2008 (CST)
  • The 353 design uses 2 DMA fifos between the compressor and the system interface instead of one in the 333 design. Is it possible to keep only one 333 DMA fifo in the final design ?
    • Yes, of course - but this is so minor difference. The more important is that in Theora that FIFO could make the compressor wait if ETRAX DMA is not ready - at the beginning of the frame in theora there is a data "burst".--Andrey.filippov 10:24, 25 February 2008 (CST)
  • In the 353 design, all signals and blocks I/O concerning 90° phase clock are commented. Is it possible to uncomment them in order to restore the clock ?
    • Maybe yes, more likely no. 353 and 333 use different FPGAs.--Andrey.filippov 10:24, 25 February 2008 (CST)
  • Motion compensation seems not to be implemented in the Theora compressor yet. Is it possible to add this feature later in the compressor block without major changes in the final design ?
    • No, I'm afraid that is not possible - I believe we need faster FPGA for that and likely faster/wider memory.--Andrey.filippov 10:24, 25 February 2008 (CST)

--JeremViewsurf 02:43, 25 February 2008 (CST)


I'm currently working on the FPGA control register and I have a question concerning the I2C pads controlled by the control register (via dcr[16:21]). In the 333 design there are 2 I2C "channels" : (sda0,scl0) and (sda1,scl1) and only one on the 353 design. Is it possible to keep a single i2c channel on the new design ? In other ways, what is the purpose of the i2c "channels" in each device ? --JeremViewsurf 03:19, 3 March 2008 (CST)

The later 353 software also has 2 I2C channels, similar to 333. One channel is designed to communicate to the sensor (and goes through 30-pin flex cable), the other - to additional boards that sit on top of the 353, that I2C bus uses 2 bits (0,1) of the 12-bit GPIO of the 353 FPGA. It is currently used by multiple I2C peripherals on teh 10369 board (IDE bus configuration, clock/calendar, temperature sensor/fan control, EEPROM, USB hub configuration --Andrey.filippov 12:27, 5 March 2008 (CST)


I tried to implement the new design according to the specs I proposed on this article. I instantiated the Theora compressor and the 8-channel memory controller in the place of the former jpeg compressor and memory controller and adapted registers and addresses (see article). The synthesis of this design with ISE is completed without error but I expect more issues with the place & route procedure. It would be great if I could share this work on a CVS to have some critics and some support, we had a discussion about that with Alexandre but I'm still waiting for an account. Before going farther, I'm trying to run the simulation with Icarus but I'm experiencing some issues with the compilation : 

channel0.v:154: error: operand of concatenation has indefinite width: ({1'b0, ntile_y[9:0]})+('sd1)
channel1.v:152: error: operand of concatenation has indefinite width: (ntile_x[3:0])+('sd1)
channel1.v:155: error: operand of concatenation has indefinite width: ({1'b0, ntile_y[9:0]})+('sd1)

I would appreciate some support concerning how to test and debug the new design since this seems to be a tough issue to deal with.

When simulating Theora I used Silos III simulator on Windows, some work is needed to make it work with Icarus. First step - patch Xilinx unisim library, then - go through code (maybe it needs width for sd1?. The other problem that will come out - in Silos tasks were reenterable, each instance having it's own set of local variables (I used it when simulating CPU interrupts), in Icarus - they all share the same.--Andrey.filippov 12:27, 5 March 2008 (CST) --JeremViewsurf 08:57, 5 March 2008 (CST)

I fixed the previous compilation error in Icarus, in channel0.v and channel1.v replace 

channel0.v:154: error: operand of concatenation has indefinite width: ({1'b0, ntile_y[9:0]})+1
channel1.v:152: error: operand of concatenation has indefinite width: (ntile_x[3:0])+1
channel1.v:155: error: operand of concatenation has indefinite width: ({1'b0, ntile_y[9:0]})+1

with 

channel0.v:154: error: operand of concatenation has indefinite width: ({1'b0, ntile_y[9:0]})+11'h1
channel1.v:152: error: operand of concatenation has indefinite width: (ntile_x[3:0])+4'h1
channel1.v:155: error: operand of concatenation has indefinite width: ({1'b0, ntile_y[9:0]})+11'h1

I can finally visualize some chronograms in gtkwave however I'm using the old 353 testbench... Time to understand how the testbench is structured and to think about a smarter one to test the new design. --JeremViewsurf 03:13, 6 March 2008 (CST)

Retrieved from "https://wiki.elphel.com/index.php?title=Talk:Porting_Theora_to_353_cameras&oldid=4417"