FPGA Central

Hi all,

I'm working on an FPGA implementation of an image processing algorithm.
I'll be using the ML401 to do the job which has DDR memory and a VGA
port to output the image directly on screen. Should I go with a
microblaze solution? EDK comes with DDR and VGA controllers for this
board, however I'm not at all familiar with it regarding the buses and
stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
memory controller and I've also found a VGA/LCD display module on
opencores.org. So both solutions seem viable to me (or do they not?),
which path should I choose? Please comment. Thanks!

"fpganovice" <[email protected]> wrote in message
news:[email protected] oups.com...
> Hi all,
>
> I'm working on an FPGA implementation of an image processing algorithm.
> I'll be using the ML401 to do the job which has DDR memory and a VGA
> port to output the image directly on screen. Should I go with a
> microblaze solution? EDK comes with DDR and VGA controllers for this
> board, however I'm not at all familiar with it regarding the buses and
> stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> memory controller and I've also found a VGA/LCD display module on
> opencores.org. So both solutions seem viable to me (or do they not?),
> which path should I choose? Please comment. Thanks!
>

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:
> "fpganovice" <[email protected]> wrote in message
> news:[email protected] oups.com...
> > Hi all,
> >
> > I'm working on an FPGA implementation of an image processing algorithm.
> > I'll be using the ML401 to do the job which has DDR memory and a VGA
> > port to output the image directly on screen. Should I go with a
> > microblaze solution? EDK comes with DDR and VGA controllers for this
> > board, however I'm not at all familiar with it regarding the buses and
> > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> > memory controller and I've also found a VGA/LCD display module on
> > opencores.org. So both solutions seem viable to me (or do they not?),
> > which path should I choose? Please comment. Thanks!
> >
>
> 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

"fpganovice" <[email protected]> wrote in message
news:[email protected] oups.com...
> 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?
>
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:
> Hi all,
>
> I'm working on an FPGA implementation of an image processing algorithm.
> I'll be using the ML401 to do the job which has DDR memory and a VGA
> port to output the image directly on screen. Should I go with a
> microblaze solution? EDK comes with DDR and VGA controllers for this
> board, however I'm not at all familiar with it regarding the buses and
> stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> memory controller and I've also found a VGA/LCD display module on
> opencores.org. So both solutions seem viable to me (or do they not?),
> which path should I choose? Please comment. Thanks!

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:
> Hi all,
>
> I'm working on an FPGA implementation of an image processing algorithm.
> I'll be using the ML401 to do the job which has DDR memory and a VGA
> port to output the image directly on screen. Should I go with a
> microblaze solution? EDK comes with DDR and VGA controllers for this
> board, however I'm not at all familiar with it regarding the buses and
> stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> memory controller and I've also found a VGA/LCD display module on
> opencores.org. So both solutions seem viable to me (or do they not?),
> which path should I choose? Please comment. Thanks!

Does a ML301 has a video DAC? Opencores VGA/LCD controller needs three
8 bit DACs!!!!.

Guru



Guru 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:
> > Hi all,
> >
> > I'm working on an FPGA implementation of an image processing algorithm.
> > I'll be using the ML401 to do the job which has DDR memory and a VGA
> > port to output the image directly on screen. Should I go with a
> > microblaze solution? EDK comes with DDR and VGA controllers for this
> > board, however I'm not at all familiar with it regarding the buses and
> > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> > memory controller and I've also found a VGA/LCD display module on
> > opencores.org. So both solutions seem viable to me (or do they not?),
> > which path should I choose? Please comment. Thanks!

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 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:
> > Hi all,
> >
> > I'm working on an FPGA implementation of an image processing algorithm.
> > I'll be using the ML401 to do the job which has DDR memory and a VGA
> > port to output the image directly on screen. Should I go with a
> > microblaze solution? EDK comes with DDR and VGA controllers for this
> > board, however I'm not at all familiar with it regarding the buses and
> > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> > memory controller and I've also found a VGA/LCD display module on
> > opencores.org. So both solutions seem viable to me (or do they not?),
> > which path should I choose? Please comment. Thanks!

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.


[email protected] 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 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:
> > > Hi all,
> > >
> > > I'm working on an FPGA implementation of an image processing algorithm.
> > > I'll be using the ML401 to do the job which has DDR memory and a VGA
> > > port to output the image directly on screen. Should I go with a
> > > microblaze solution? EDK comes with DDR and VGA controllers for this
> > > board, however I'm not at all familiar with it regarding the buses and
> > > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> > > memory controller and I've also found a VGA/LCD display module on
> > > opencores.org. So both solutions seem viable to me (or do they not?),
> > > which path should I choose? Please comment. Thanks!

I'm using an ML401. It does have a DAC from analog device.

Guru wrote:
> Does a ML301 has a video DAC? Opencores VGA/LCD controller needs three
> 8 bit DACs!!!!.
>
> Guru
>
>
>
> Guru 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:
> > > Hi all,
> > >
> > > I'm working on an FPGA implementation of an image processing algorithm.
> > > I'll be using the ML401 to do the job which has DDR memory and a VGA
> > > port to output the image directly on screen. Should I go with a
> > > microblaze solution? EDK comes with DDR and VGA controllers for this
> > > board, however I'm not at all familiar with it regarding the buses and
> > > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the
> > > memory controller and I've also found a VGA/LCD display module on
> > > opencores.org. So both solutions seem viable to me (or do they not?),
> > > which path should I choose? Please comment. Thanks!

> > Guru wrote:
> > > 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.

Without any performance criteria, this is absolutely meaningless
advice.

fpganovice wrote:
> [email protected] 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.
>
> 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.

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
90%+.

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.

---
Erik Widding
President
Birger Engineering, Inc.

(mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
(fax) 617.695.9234
(web) http://www.birger.com

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 Widding wrote:
> > > Guru wrote:
> > > > 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.
>
> Without any performance criteria, this is absolutely meaningless
> advice.
>
> fpganovice wrote:
> > [email protected] 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.
> >
> > 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.
>
> 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
> 90%+.
>
> 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.
>
> ---
> Erik Widding
> President
> Birger Engineering, Inc.
>
> (mail) 100 Boylston St #1070; Boston, MA 02116
> (voice) 617.695.9233
> (fax) 617.695.9234
> (web) http://www.birger.com

fpganovice wrote:
> 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...

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.


---
Erik Widding
President
Birger Engineering, Inc.


(mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
(fax) 617.695.9234
(web) http://www.birger.com