[Elphel-support] Rép. : Re: Fpga Firmware

[André Pouliot]

>>> Andrey Filippov <andrey at elphel.com> 2010-06-09 17:22 >>>


On Wed, Jun 9, 2010 at 1:40 PM, André Pouliot
<andre.pouliot at cegeptr.qc.ca> wrote:


Where I work, what we intent to do is, to offload processing to the
camera so that we can detect when something of interest happen. This
event would send a signal to an operator who could then look at the
camera. 


Hi André,

What kind of processing do you have in mind? There are three places
where it is relatively easy to connect to existent code.

First is the data path from the sensor to the "video" SDRAM connected
to the FPGA. This is where scaling, gamma-conversion, histograms
calculation is taking place. Video data is available in scan-line order,
there are two clocks available - sensor rate (96MHz with 5MPix sensor)
and double pixel rate (192MHz), that clock is used in histograms
module.

The second place is in front of the compressor, where the data is
subject (or bypassed) color conversion. Here the data is getting from
the memory in 20x20 overlapping (period is 16 pixels, 4 pixels overlap).
That module is clocked at half system clock (160/2=80MHz).

Next place - inside the compressor after the DCT - here you can make
use of the average values fro 8x8 pixel blocks and different high
frequency components - we use it in "focus helper" application.
 
The processing I have in mind is  edge detection and after that some
algorithm to help in form recognition and motion detection using
background subtraction. The background being continuously updated. I can
use the acces in the second place before the compressor to acces the
data, but I also need a memory access where to put some intermediate
result.




That being said. I was looking at the different resources available on
the processing board. After consideration I determined that only the
FPGA is available for anything with important algorithm requirement. 


What do you mean by "only the FPGA" . What other resources were you
looking for?
 
The Axis can do some processing but it's there more for control, not to
do any kind of processing with math requirement.



For the last few days I was looking at the code in the FPGA. To try to
see how it work. I must say it took me quite some time to be able to
graph the general data flow between the different modules and how
everything seem to be connected together. After doing that I know that
the system work and where I could connect the module I plan to develop.
But even that will need some change to the underlying code to be able to
work.


I was counting on that top-level graphs available in the Xilinx Xcell
and LinuxDevices magazines. Unfortunately I recently noticed they are
all offline by now and our links there are dead.I'll need to find the
drafts and try to restore them.
 
That would be most helpful I was actually using a large white paper
sheet white post-it on it to work. 



What I would really like would be if it was possible to do a code
reorganisation. I know it's something quite massive, I would suggest to
do it step by step. But it will help in the long run when developing
FPGA code. I'm not suggesting a code rewrite of the modules but on the
top level a few change. Something that we would discuss first.
Reorganise the code so the architecture become simpler. It would become
easier for a new developer to become involved. And it would help with
code portability in the long run.


Yes that code base is not as clear as I would like to see it. Some
pieces where written back in 2002 when I was just starting to work with
Xilinx FPGA, some parts of the code where made for the synthesis tools
that supported less of the Verilog than they do now. I did make some
clean-ups during these years, but I was not planning major overhaul
until moving to the next 373 camera.
 
If we start doing a small overhaul right now, at least a code
reorganisation, doing the overhaul for the 373 will be simpler and the
code will be more easy to figure where the overhaul is needed.



For example the registers to become embedded in their dedicated
modules, so we only have one command bus. 


I was trying to keep top module free of registers (just wires between
modules) but the sneak in (mostly for debugging). And there is a command
bus there to write data to internal registers/tables. It has multiplexed
data (two cycles of 16 bit wide).
 
Not sure if I understand you well. You didn't what top modules to have
register, only wire between their register and the modules?


Reorder how some modules are placed in the files so that the modules
that work together are together. Also make each modules in it's own
files so we can find it more easily.

Yes, you are right. And I did split most modules into separate files
during previous partial clean-ups, but not all of them. So there is
still work to be done.


I have a few more idea. If someone is interested, I'll be waiting for
your reply


Thank you, that may really help. Do you have 10359 board? It may be
easier to use it for the image processing as the rest of the camera does
not depend on it as heavy as on the system board FPGA.

Andrey
 
No I don't have a 10359 board we only use a single sensor so I couldn't
justify the need for it. Maybe it would be easier to do the processing
there I don't know.
 
André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100610/f95b6598/attachment-0002.html>