DSP or FPGA for high-speed image processing??

[kyori]

Hi,

I am going to start a project of onboard high-speed CMOS image
processing.
I am goint to perform certain *block matching algorithm* or *Fourier
Transform* between successive frames and the fps would be 1000 or
more..


The interface between the CMOS camera and the board is standord
CamLink.
I've learned that both DSP and FPGA based circuits can do certain
onboard image processing tasks, and I'd like to know whick is better?
DSP or FPGA?


I know some corporations use FPGA based boards as development boards
for their cameras. And my cooperators have some DSP development
experiences. So, the question arises, and I want your suggestions. I'd
like to know the advantages of each choise and maybe the direction of
onboard realtime high-speed image processing.


Thanks!
Any help would be appreciated.

 

[David L. Jones]

Hi,

I am going to start a project of onboard high-speed CMOS image
processing.
I am goint to perform certain *block matching algorithm* or *Fourier
Transform* between successive frames and the fps would be 1000 or
more..


The interface between the CMOS camera and the board is standord
CamLink.
I've learned that both DSP and FPGA based circuits can do certain
onboard image processing tasks, and I'd like to know whick is better?
DSP or FPGA?


I know some corporations use FPGA based boards as development boards
for their cameras. And my cooperators have some DSP development
experiences. So, the question arises, and I want your suggestions. I'd
like to know the advantages of each choise and maybe the direction of
onboard realtime high-speed image processing.

DSP could have the following advantages:
1) Familiarity. A DSP uses a standard sequential programming language
like C that you are no doubt already familiar with, as are your
colaborators by the sound of it. There should also be plenty of code
examples available for such image processing tasks. If you have used a
microcontroller, then a DSP is essentially the same thing, except much
faster.

2) Tools are much cheaper, simpler, and more robust. FPGA tools can be
horrid to set up and get working. If you are not familiar with FPGA
development tools you will have a massive learning curve.

3) DSPs are ideally suited to doing FFTs. You can get FFT "cores" for
FPGA's, but it's just easier in a DSP.

An FPGA might have the following advantage:
1) Speed. Because an FPGA is dedicated hardware, you can most likely
achieve a greater real-time data throughput.

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

 

[Nico Coesel]

DSP could have the following advantages:
1) Familiarity. A DSP uses a standard sequential programming language
like C that you are no doubt already familiar with, as are your
colaborators by the sound of it. There should also be plenty of code
examples available for such image processing tasks. If you have used a
microcontroller, then a DSP is essentially the same thing, except much
faster.

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.

2) Tools are much cheaper, simpler, and more robust. FPGA tools can be
horrid to set up and get working. If you are not familiar with FPGA
development tools you will have a massive learning curve.

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.

 

[linnix]

DSP could have the following advantages:
1) Familiarity. A DSP uses a standard sequential programming language
like C that you are no doubt already familiar with, as are your
colaborators by the sound of it. There should also be plenty of code
examples available for such image processing tasks. If you have used a
microcontroller, then a DSP is essentially the same thing, except much
faster.

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

2) Tools are much cheaper, simpler, and more robust. FPGA tools can be
horrid to set up and get working. If you are not familiar with FPGA
development tools you will have a massive learning curve.

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

3) DSPs are ideally suited to doing FFTs. You can get FFT "cores" for
FPGA's, but it's just easier in a DSP.

An FPGA might have the following advantage:
1) Speed. Because an FPGA is dedicated hardware, you can most likely
achieve a greater real-time data throughput.

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

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.

I vote for FPGA.

 

[Tim Wescott]

-- snip --

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.

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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Nico Coesel]

-- 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.

 

[[email protected]]

Let take a look a practical number, for example a high end process can
handle 1280x1024 @60 fps or the bandwidth is about 78 MB/s. If
increase the frame rate to 1000 then resolution is about 78 KB. This
image is much larger than 4x4, isn't it ?

 

[Joel Kolstad]

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.

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.

 

[[email protected]]

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.

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

Michael

 

[Nico Coesel]

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

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

 

[jasen]

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 it's for an optical mouse that'd be massive overkill...

Bye.
Jasen

 

[kyori]

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

 

[kyori]

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