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
_______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
