EDK vs. ISE for image processing

If you don't need a CPU, then you don't need EDK either. If you do need a CPU, it is much easier to use EDK. However, if you decide not to use EDK you will probably have to spend more time interfacing your pieces, e.g. the opencores VGA controller probably needs a Wishbone bus...

On the side note, it might be worth mentioning that some of the EDK ready-to-use cores are behind performance-wise from what is generally available, e.g. I believe MIG allows for faster DDRAM interfaces than you could achieve by using any of the EDK memory controllers.

/Mikhail

Hi Mikhail,

Thanks for your reply. The VGA core does use a Wishbone bus, and it has built-in Wishbone master and slave interfaces. It seems like I just need to set some registers through the slave and get access to external memory through the master. Therefore I was thinking those interfaces could connect with my FPGA hardware directly, or do I still need something to talk to the core?

Thanks again.

MM wrote:

Depending on what you mean under "directly". The MIG memory controller is not aware of Wishbone... So, you will need to do a Wishbone interface for it, however simple. The same is true for the other direction...

/Mikhail

Hi fpganovice,

Forget about MicroBlaze, you will never get the desired speed. Image processing should be done in logic ONLY. Try to figure out how you can serialize your processing algorithm to work pixel-to-pixel. This way you probably won't even need a DDR.

There is also a Xilinx thing called Multi Port Memory Controller 2 which has a fast interface to DDR, PowePC and GigaLAN. PLB_LCD (native LCD) controller is also included in the project cores. The only drawback is that it consumes a lot of logic, which you can use for image processing.

Cheers,

Guru

fpganovice wrote:

Oh yes, I forgot one more thing:

FPGA->VGA OPB bus driver was included in the Spartan3 starter kit Xpong project - opb_color_video_ctrl_v1_00_a.

Cheers,

Guru

fpganovice wrote:

Does a ML301 has a video DAC? Opencores VGA/LCD controller needs three

Guru

Guru wrote:

Microblaze is not so fast but why not to design microblaze plus some hardware accelerators. It could be fast enough and easy to design, I suppose.

/Wayne

Guru wrote:

Hi Wayne,

This is what I was originally thinking. I already have a VHDL module for image processing pixel-by-pixel. So I was thinking of integrating it with the microblaze and use the DDR and VGA controllers that come with the microblaze design.

snipped-for-privacy@gmail.com wrote:

Without any performance criteria, this is absolutely mean> snipped-for-privacy@gmail.com wrote:

Processors can be very useful. Don't overlook the fact that one can use the EDK without having a processor in the system. We do this with a lot of our image processing systems.

The automation that this tool provides for mixing and matching IP modules with buses can be extremely useful in any data processing application. A reference design for this board employing the MicroBlaze processor can be used as a starting point. The processor can be removed, and an OPB bus master interface attached to your existing IP can be put in its place.

Xilinx has gone to a lot of effort on the IPIF package, but it has been our experience here that if you start with CoreConnect documents from IBM it will be easier to just attach your IP directly to the OPB bus rather than through the IPIF. To start, just do single 32bit reads and single 32bit writes per bus transaction. Think of this as a sort of a "hello world", to prove that you have the basics of EDK, the PAO and MPD files and the OPB bus down. Then it will be only a minor effort to move to burst transfers. With single reads you moght find that you only get 25% bus utilization. With longer bursts you can easily get

The other sugggestion I would make relates to the architecture of your module. If you use a BlockRam with a 32bit port to attach to the OPB bus, and an 8bit (pixel width) port to attach to you IP, your IP and the bus can run asynchronously to each other (i.e. at arbitrary clock rates) and your IP does not need to know how to do anything other than handle one pixel at a time, even if you perform burst transfers. The state machines that run your OPB interface and you processing IP each need to pass a strobe to the other when it has written a burst of pixels it wants the other side to handle. Flow control is easily handled this way.

The fifo mode of the Virtex4 BlockRam does not allow for different port sizes. I wish it did. I remember having a rather heated conversation with Peter regarding this at a Xilinx gathering a few years back. It would be particularly nice for all kinds of serial/parallel conversion from bit to pixel, pixel to word, or bit to many pixels in parallel, etc. While it might take less resource to do the width conversion and use the fifo, than to implement the burst counters and not use the fifo, the later does have one added benefit. One can fit two fifos, one in each direction, into a single blockram.

Haven't yet looked at the blockrams in fifo mode in V5 yet - as all of our active designs are V4 for the rest of the year. Anybody care to comment if different port widths are supported?

Regards, Erik.

Many thanks for your reply, Erik. How would the VGA module function if the processor is removed? I remember there's a C function running on the processor that initiates the display...

Erik Widd> > > > Forget about MicroBlaze, you will never get the desired speed. Image

For a simple single video buffer (i.e. no shadow or ping-pong like buffering), you can go into the source code for the VGA module and modify the reset assignment to the registers that you care about. If I wanted to get something working fast I would do (and have done) such things.

This address could be written over some external interface that has a bus master connection to the OPB (i.e. PCI). But with the ML401 board, there is no easy way to do this. Our processorless FPGAs usually have a port such as this.

In more complicated systems, where we have circular buffers of frames being processed, we set up each IP module in the sequence to read the address of the last completed buffer from its predecessor. Given that you will be using somebody else's VGA module, you could simply have your module write the address of the next frame to the VGA instead.

Or, rather than distributing intelligence into all of your modules... You could have a simple state machine that is an OPB master that does some of the setup/housekeeping tasks. It might be as simple as a 32bit wide blockram (as a ROM) where portA is used to present an address on the bus and portB is used to present the data. A subrange of portA could store the microcode for your statemachine as well. It would only take a few extra gates to handshake with the bus, and sequence through the microcode. It might take as input a single interrupt that tells it the next frame has been processed. EDK can be used as a framework to do cool stuff like this.

In many systems there is a desire for a processor of some sort, as it just makes life easier to deal with the setup and housekeeping, as you point out. Sometimes a state machine is good enough, and much smaller. It has been 4 or 5 years since we have put a discrete processor on a board next to an FPGA, as EDK lets us do all kind of interesting "what if" architectural trade-offs in real hardware without having to rev physical hardware. EDK is an excellent tool for setting up, and modifying the dataflow in an FPGA - whther or not a processor (Microblaze, PPC, something else, etc) is present.

I had not meant to suggest that a processor was not a smart choice for your application. I only meant to suggest that it wasn't the ONLY choice. Your question to me demonstrates that you are clearly thinking through your options. Makes me feel that spending an extra few minutes writing out a more detailed answer is worth while. Nice way to end a friday - feeling appreciated. Good luck as you continue with your project.

Regards, Erik.