DSP or FPGA for high-speed image processing??

DSP could have the following advantages:

An FPGA might have the following advantage:

I'd recommned you do the calculations and figure out if a DSP can do what you want in real-time, if it looks like it can with plenty of margin then use the DSP and don't even consider using an FPGA. Perhaps it is worthwhile investing some time and effort trying DSP first as a simple prototype to get a feel if it has enough processing grunt for you.

Dave :)

If power and space permits, an Intel Core Duo CPU based mini-PC may also be an option. I don't think there is a DSP which offers more processing power.

That's not true. For example: Xilinx offers free tools which are no harder to operate than a high level language IDE (like Visual Studio or Delphi). Still, developing for FPGAs does take some experience and a thourough understanding of how the FPGA works internally if you want to push an FPGA to its limits.

You can also get a process core for FPGA, then program it as simple CPU, or CPUs.

Low end tools are cheap and often free. High end tools are expensive.

And wider data paths. For 1K (2 ^ 10) FFT, you can make 10 multiplers and run them in parallel.

I vote for FPGA.

-- snip --

This is what it really boils down to. 1000fps is easy if they're 4x4 frames, more difficult if they're 1000x1000. Look at your algorithm & figure out how many multiplies and adds it requires each second. Then look at your candidate processors, and what _they're_ capable of. If multiple processing blocks are necessary figure that it'll be easier to rope a bunch of FPGAs together in some unique fashion than DSPs, and the DSPs will be easier than the suggested mini-PC.

A lot of machine vision cameras come with fire-wire or ethernet these days. Interfacing those to a mini-pc is a matter of buying the right interface card. An Intel Core Duo CPU uses about 15W. I don't see how an FPGA or DSP solution will take less development time than just writing a piece of software. I doubt the size of the image is very large at 1000fps otherwise there will be a bandwidth problem. So a direct-show filter (which is nothing more than a com object) may do the trick. If the algorithm is known and a mini-pc offers enough processing power the entire project may be finished in less than a week.

If you end up having to write the CPU code in assembly -- and at a level where you need to be very much aware of the internal pipeline structure of the CPU to avoid stalls, as, say, Intel's imagine processing libraries do -- you're definitely looking at spending as much or more time with the CPU approach as the FPGA approach.

I agree with you that if you can get away with a DirectShow filter, someone else's highly optimized library code, etc., a CPU is the way to go.

Are FPGA development tools readily available in Zhejiang, China (where the OP is posting from)?

Michael

Yes, in the software shop around the corner for less than a dollar per DVD rom.

if it's for an optical mouse that'd be massive overkill...

Bye. Jasen

I was inclined to first buy certain DSP development board for testing and optimizing my algorithm at a lower fps. Because my cooperators have some experiences on DSP.

Now I think that I should first put more efforts on the algorithm. I am going to learn some basics of DSP, FPGA, and the mimi-PC and consider implementation of my algorithm. (how many multiples, adds, fft or in parallel way, etc...)

The frames size will be less than 256*256.

Thanks for all your advices. It is my first time dealing with DSP, FPGA or mini-PC, and thanks for your patience with my naive questions. ;-)

kyori

David L. J> > Hi,

Yeah.. I'll buy the development board first and maybe including the software.

I have a friend in Chengdu in Sichuan province who is also a student. He is interested in FPGA development.

kyori

snipped-for-privacy@gmail.com wrote: