Suggest device for 100+ FPS camera board

Hello,

I'm a researcher trying to build a device that grabs RAW monochrome VGA images from a fast, LVDS camera (100+ frames per second) and stores them onto a SD card, and also drives a touch LCD (plus a trifle little other logic)

I'm wondering what would be the correct development platform for this? Should I go with an ARM based system OR a FPGA+ARM based one OR a FPGA alone.

I'm confused since I have never worked professionally with high speed designs and hence am wondering (especially after reading through some posts) if even a 1 GHz ARM can handle that kind of data flow.

The experienced designers - could you please suggest something? Thanks a ton !!!




BTW, the device is for a medical diagnostic method and is envisioned to be mass-marketable and hence needs to be low cost (which is why I'm :bang: at the PYTHON300 image sensor from OnSemi instead of buying a ready-made but costly USB camera).

If you want to drive an LCD, then you're going to need a processor. If you want to do some image manipulation before storage then the FPGA will be idea for that.

You havent said what kind of resolution and pixel rate this image is. and the bit depth?

TrickyDicky said:

If you want to drive an LCD, then you're going to need a processor. If you want to do some image manipulation before storage then the FPGA will be idea for that.

You havent said what kind of resolution and pixel rate this image is. and the bit depth?

Click to expand...

Thanks.

I need very little image manipulation (maybe a little image cropping and such).

I said VGA resolution. But forgot to mention that it's at 8-bit or 10-bit depth (depending on what image quality I get).
And the pixel rate would be ~300K pixels per image x 100+ images per second = 30 M pixel /sec
And the corresponding data rate would be 30 M pixel /sec x ~1 byte/pix = 30 MegaByte per second (atleast).

That really isnt that much data
Im an FPGA guy, but that volume of data into/out of an ARM should be ok.

prateek_k_chd said:

the device is for a medical diagnostic

Click to expand...

Depending on the kind and amount of real time processing required, an approach based only on an ARM core may be overloaded, leading it to the limit of its capacity.

TrickyDicky said:

That really isnt that much data
Im an FPGA guy, but that volume of data into/out of an ARM should be ok.

Click to expand...

AFAIK, what andre has said stands true. And even more so with Linux. I see lots of context switches even when no "extra" software is running...and a processor, I suspect, would miss out on some frames. UNLESS I could get a 2-core or 4-core processor and dedicate a core solely to capturing images. And even then there's the issue of what GPIO or othe peripheral could manage that data rate (given that it's serial data).

So I'm hoping someone with experience in programming real-time multi-core ARM systems could shed some light on this.
Or maybe someone familiar with FPGAs could share a few tips !

Thank you, both of you

I´m not expert in FPGA, but in my lay sight what Tricky mentioned above seems perfectly feasible if you consider using some ARM core built in together with a GPU unit. Anyway, you did not mentioned yet the application, neither the principal functions required, as well if it will be done real time or furhter.

andre_teprom said:

I´m not expert in FPGA, but in my lay sight what Tricky mentioned above seems perfectly feasible if you consider using some ARM core built in together with a GPU unit. Anyway, you did not mentioned yet the application, neither the principal functions required, as well if it will be done real time or furhter.

Click to expand...

I could get an ARM+GPU - am currently thinking of using a Beaglebone black or RPi2.

Sorry I missed these details but I do need a real time unit. The principal function is to grab images from the sensor as fast as possible and store them on to a SD card (or some other memory) so that these images can later be processed (for medical diagnostic). The end application is portable disease diagnosis (more details at http://iap.iisc.ernet.in/~saisiva.gorthi/research.html)

If I understood correctly, the system will not perform realtime processing, but just store images at an embeded memory, correct ? The Beaglebone Black is based on the Allwiner A20 uP, that supports the video H.264 format, so that by using the cheapest known webcam ($30) which encode with that standard, you could avoid the need of an FPGA acceleration, but I´m not sure if would achieve the 100fps rate as you mentioned above. A real testbench is required to determine it precisely.

andre_teprom said:

If I understood correctly, the system will not perform realtime processing, but just store images at an embeded memory, correct ? The Beaglebone Black is based on the Allwiner A20 uP, that supports the video H.264 format, so that by using the cheapest known webcam ($30) which encode with that standard, you could avoid the need of an FPGA acceleration, but I´m not sure if would achieve the 100fps rate as you mentioned above. A real testbench is required to determine it precisely.

Click to expand...

Yes Andre, that's all the need as of now.
The whole issue is about interfacing to a particular camera chip, else it all would've been done by now