[Elphel-support] Simple Video processing with Elphel cameras

[Andrey Filippov]

Hi Leonardo,

Does your camera have the 10359 board (
http://wiki.elphel.com/index.php?title=10359 )?

It is much easier to experiment with this board for custom FPGA processing,
as while re-compiling the main FPGA you may encounter the following
problems:
1 - Xilinx keeps updating their software and it looses compatibility with
existent code. Current code for the system FPGA does not work with v.11 of
Xilinx Webpack - it needs version 10 (10359 code is simpler, it can work
with the latest version)
2 - Compilation time - the system board FPGA has much more code to be
compiled and placed and routed, so each iteration takes some time
3 - It is easy to break some of the existent features, FPGA code errors can
easily cause system bus conflicts (FPGA shares system bus with CPU and some
memory), such conflicts can even cause overheating of the CPU and/or FPGA if
you do not disconnect the power fast enough, so you should be very careful
when making any changes to the FPGA part related to I/O, make sure the UCF
file with pinout designations is always used by the tools
4 - meeting timing constraints to the existent part of the design can be
sometimes tricky and you need to run multiple iterations after you add some
new code.

Working with 10359 boards is easier, problems in the FPGA do not lock up the
system as it does not share the system bus. But sure it is possible to add
the required functionality to the main FPGA too. If you need the array of
heights as function of X, I would suggest turning camera 90 degrees and
generating 1 number per (vertical) scan line, adding such module between the
sensor input and the video memory. As the amount of data is much smaller
than the video frame itself, I would recommend using embedded RAM (BRAM)
module, fill it with data and than read it by the CPU with auto-incrementing
addresses - you may use histograms as an example of such reading BRAM.

FPGA code for the system board and for 10359 is included in the code tree
(under fpga subfolder), the source code is included in each camera and at
Sourceforge. Here is a link to the CVS browse:
http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/fpga/ . The
individual FPGA subfolders (i,e, x3x3 for the system board) have all Verilog
source files, ucf and the script to re-create a project for Xilinx Webpack -
there are also outputs from the tools, so you may compare results there with
ones you'll get when running tools yourself.

To start working with Elphel code I would recommend to start with
instructions here:

http://wiki.elphel.com/index.php?title=Elphel_Software_Kit_for_Ubuntu

If you are experienced GNU/Linux user, you may adjust the recommendations on
that page to the distribution you are using. If you are new to GNU/Linux I
would suggest to install Kubuntu 9.10 and follow the instructions closely,
you should get a complete development environment as a result, same one as
we are using at Elphel. To try a new (system board) FPGA in the camera you
just need to replace the *.bit file in the camera /etc/ directory and reboot
the system. And of course when you are making changes to the camera code it
is very helpful to have a serial port connected to the computer running some
sort of a terminal emulator (i.e. minicom) so you'll see the boot messages,
debug output and be able to run commands - otherwise if something goes wrong
camera may never finish the startup tasks and so will silently refuse to
communicate over the network, that would require low-level reflash. And I
would recommend you to familiarize yourself with such procedure before
making any changes to the camera software - our experience shows that while
developing new software it is rather likely to end up with un-bootable code
that requires such reflash.

So I hope the above answers you first questions. Next one - yes, we are
migrating to the new CPU and new FPGA, you are right - it ids the 10373
camera board I'm working on.

Using large FPGA to replace CPU - no, we do not plan that. We need multiple
of the general computer functionality (general CPU power, GigE, USB, SATA,
...) that is nicely implemented in the specialized SOC devices,
re-implementing them on FPGA will require a lot of additional development
and will result in less efficient system (less speed, more power
consumption). So I believe FPGA and general purpose CPU (SOC with integrated
peripherals) nicely complement each other.

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100314/bdb66efe/attachment-0002.html>