Before anyone say something negative about my post, yes, i have already read a lot of other posts before i public this question (well maybe not A LOT) but still i have doubts.
I'd be really glad if someone can guide me, first i'll explain what i want to achieve and what i know.
My purpose is to make an edge detector with pure VHDL (HLS is a valid option) an FPGA with Vivado Design Suite (with pure i mean without using any external help like pre built IP cores or toolkits form xilinx, etc), im between a Zybo fpga with zynq 7000 msoc, or an kintex with enough RAM to load a low quality image.
I already have some VHDL knowledge but i have never worked with image processing with a FPGA.
Here i go.
-
IS it even possible to make a real time color image processing in FPGA without using any external Software or Hardware, like MATLAB, and to be able to read an image from a camera and after the processing, display it on a screen with VGA connection or something like that? AND of course, synthesizable.
-
First, which is the best (in terms of difficulty and performance) format file to load an image to fpga BRAM. I have read some posts saying that .bin, .hex, .mif and .coe, but which is the right one? I pretend to read a grayscale image, and after that, a color image.
-
Could someone give me an example (some explaining would be perfect) in vhdl to read a .coe/hex/etc file? Or link me to a good source of knowledge on how to do that.
-
Is there any book about image processing with fpga with some examples?
and thats it.
I would really be grateful if someone could guide me.
Best Answer
The answer, as usual, is "it depends".
Your main obstacle is memory size. FPGA block ram tends to be on the order of a few hundred kilobytes to tens of megabytes in the high end chips, and it's organized differently, as hundreds of small patches rather than one big chunk.
So an algorithm that operates on a big area would synthesize to a single copy of that algorithm, an address decoder that takes the upper bits and decides which patch of RAM to address, and lots of interconnects. At runtime, most of the chip would be idle, with a small part running with a slow clock, because the interconnects are rather long. You can optimize a bit by adding pipelines and designing your algorithm to operate on tiles (which is doable for edge detection, although difficult on tile boundaries), but in general memory size will still be too little.
A sensible FPGA based design would probably use external DDR memory, but we are in the midrange segment there already.
VGA output is not a big deal, you just need a set of DACs and a tunable clock source to generate the pixel clock (the FPGA onboard PLLs are usually not flexible enough). For HDMI, you just need differential outputs that are fast enough (mid-range segment again) and a clock source, so that is even less effort.
Generally, you wouldn't use the block ram initialization formats to load image data, these are used in FPGA initialization only. Instead, you'd leave the block ram uninitialized during load and implement a small state machine that can be used to transfer data in. To get data from a camera that would probably be a MIPI interface.
One thing you can probably do is stream the image processing. For edge detection, you mostly need to compare adjacent pixels, which you get basically for free horizontally as the pixels are transferred right after another, and with a small buffer holding a few lines for vertical and diagonal tests.