CCD and Graphics - which FPGA?

Hi all,

some years have gone since I did something with FPGAs and I am aware that technology has moved forward significantly since the end of the last century ...

We now think about reading out some CCD sensors and doing image processing with an FPGA. My questions to you:

- do you think this is feasable?

- which FPGA would you recommend?

- Which language would you recommend?

We have used Xilinx and Handel-C so far and hence would prefer to stick to them. But if there are good arguments against it we would certainly follow them.

Thanks a lot for your advice,

Christian

Reply to
C. Peter
Loading thread data ...

Sure, but what kind of application? A simple one can be done in software.

Again, what algorithms, what size of image, how many images/second... and most important, how much are you eager to spend for each device?

No other choice yet than Verilog/VHDL...

Reply to
Stephane

Correct. CMOS sensors has also evolved forward significantly since the beginning of this century. If you are not expecting the CCD type of image quality, CMOS delivers the higher quantity of pixels at lower cost than CCD.

This website is helpful to you.

formatting link

Reply to
Acceed See

Hi.

I specified a system-on-chip for 6Mpix. digital camera @ Philips Semiconductors and we did exactly what you intend to do but w/ an ASIC. On-the-fly video/image processing + JPEG compression + storage/communication interfaces + RISC processor requires ~ 1Mgates/ASIC that I would convert to

6-8Mgates/FPGA. I would go for a Xilinx XC3S5000 (Spartan-III family) or a Xilinx XC4VLX80/XC4VFX100 (Virtex-IV family). What you plan is probably feasible but it will require a lot of efforts.

For the language, I would choose VHDL but I don't want to restart an endless war on which HDL languages is the best one ;-) My motivation would be a strong syntax which probably results in less bugs during the design. For such a big development, you shouldn't neglect the verification effort that you'll face.

Eric

Reply to
Eric DELAGE

Greetings, Comments inline below...

C. Peter (die_les_ich snipped-for-privacy@gmx.net) wrote: : Hi all,

: some years have gone since I did something with FPGAs and I am aware that : technology has moved forward significantly since the end of the last : century ...

: We now think about reading out some CCD sensors and doing image processing : with an FPGA. My questions to you:

When you say "reading out some CCD..." does this include generating the various readout waveforms for the CCD? FPGAs make excelent waveform generators for controling a CCD, and can be much better suited to this task than a CPU, although care is needed with the timings.

So yes an FPGA is good for readout control, but whether it is good for image processing depends on the nature of the processing. If you ask yourself "are my processing algorithms highly deterministic?" and the answer is "yes", then the FPGA is likely a good choice. If the answer is "actually no, our reference C code is full of conditional branches and uses different algorithms bassed on the image content etc." then more consideraton is needed.

Cheers, Chris

: - do you think this is feasable? : - which FPGA would you recommend? : - Which language would you recommend?

: We have used Xilinx and Handel-C so far and hence would prefer to stick to : them. But if there are good arguments against it we would certainly follow : them.

: Thanks a lot for your advice,

: Christian

Reply to
c d saunter

Hi all,

thank you very much for your answers and questions. I now have some more specifics about the system-to-be:

- there are 4 ccd cameras with 1024 pixel which are read out each by 1 FPGA (Spartan) - this is already done and the system we want to build our's on.

- those FPGAs behind the CCD cameras send out byte arrays. We aim at producing about 60 MByte/sec

- our part now is to read those byte arrays (all 4) and do edge detection on it. This has to be done in real-time.

- if this is too heavy we could imagine doing the edge detection separate for each of the 4 data streams (still in real-time), although this would result in significantly more work to be done in consecutive steps.

- The parameters of the edge detectors must be configurable in near real-time.

- The output of our FPGA(s) is a figure for number and size of identified objects of interest.

Well now, do you still think it is feasable? Would a Spartan 3 do it or is a Virtex needed (one with DSP slices)?

I very much appreciate your input!

Thanks a lot,

Christian

Reply to
C. Peter

Line scan cameras, then. OK. As you say below, they usually produce data slightly faster than typical video-compatible area cameras.

If the edge detection is one-dimensional, in the direction of the line scan, this is very easy indeed and would fit in even the cheapest modern FPGA. However, if your edge detection needs 2-D processing as I guess it does, then you need to store recent video lines and you will certainly need lots of bandwidth to internal memory because you need access to more than one line to process each pixel.

It depends on the edge detection algorithm. Something simple like a 4-point Sobel would cause no trouble at all. Edge detectors with more complex branching algorithms (Canny?) would be much trickier.

In itself this is unlikely to be a problem. You have several dead pixel times at the end of each line; during this time you can copy parameters, from a RAM where they've been written by software, into the registers where they will be used.

So presumably you are not only edge detecting, but also keeping track of those edges and inferring object outlines from them? That kind of task typically creates variable-sized data structures, which don't map on to FPGA implementation very well unless there are other application-specific constraints that you can exploit in the algorithm design. Depending on the exact nature of the object-finding, this may be good work for a small embedded CPU (Microblaze etc) in the FPGA.

You'll need to be much more specific about the edge detection and discrimination algorithms. Things like how many multipliers (if any) are needed by the area convolution operations.

We, and many other organisations, would be in a good position to help with specifics of implementation - but there's no way you can start to estimate required hardware resources until you have a clear description of the required algorithms. Only then can you begin to bash the algorithms into an FPGA-friendly form and start allocating hardware to them.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223          mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.
Reply to
Jonathan Bromley

Dear Jonathan,

thank you very much for your input, it helps me a lot in understanding the problem. I will dive deeper into the algorthims now. As for the rough hardware estimates, I understood you that if we want to do object detection with resulting variable-sized data structures, we should go for an FPGA with embedded CPU. I will probably come back to you later, when I have a deeper understanding of the problem and possible solutions.

Thank you very much so far,

Christian

-- J> >

Reply to
Christian Peter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.