VHDL and Image processing.

A

Amit

Guest
Hello group,

Does anybody know how should I a newibe like me can get started on
VHDL and Image Processing?

I have purchased Altera DE2.

Regards,
Amit
 
On Tue, 04 Sep 2007 00:51:27 -0700, Amit <amit.kohan@gmail.com> wrote:

Does anybody know how should I a newibe like me can get started on
VHDL and Image Processing?

I have purchased Altera DE2.
The obvious Google search will bring up lots of hits, but first
I suggest you should concentrate on getting the basics in place.
I don't know the Altera DE2 board, but whatever, make sure you
know how to get an image into its on-board memory, and how to
display that image on a monitor of some kind. Once you've done
that, consider doing some REALLY simple operation on every pixel
in the image - for example, make the image negative - and check
that works by simply looking at the displayed result.

Having done those things, you are probably ready to do some
more interesting image processing operations. First, try to
implement a 3x3 moving-average filter over the image - for
each pixel, compute the average of that pixel and its eight
immediate neighbours, and use that average as the output
pixel value. Again your success or failure can easily be
confirmed by inspection of the displayed image, and it's
a good way to start thinking about the addressing issues
(how do you access a pixel's near neighbours?).

Now you're ready to do just about any of the classic image
processing operations such as edge detection, contrast
enhancement and so on; you can start concentrating on the
image processing problems, because you will by then
understand how to implement it in the FPGA. It should also
be an easy step from there to doing image compression tasks
like DCT.

The next step is to start considering geometrical operations
such as rotation and scaling. These tend to be quite a bit
harder in FPGAs because they need complicated address
calculations that don't have the simple locality that you
find with filtering operations.

Depending on what peripheral hardware you have with your
development board, you may or may not be able to implement
these operations in real-time on a video stream. If so,
you can then consider operations *between* images, rather
than *within* a single frame; that step allows you to do
stuff like motion estimation as well as some interesting
compression and noise-reduction tricks. But it will
require you to manage quite a lot of memory.

I think that the message I'm trying to convey is this:
Image processing on an FPGA is, in principle, no different
than image processing in software. However, the very
different resources on an FPGA compared with a software
platform mean that the main practical difficulties are
likely to be issues like memory access and video interfacing,
rather than the theory of the image processing itself.
Your reward for mastering those difficulties, of course,
will be astonishingly high throughput - if you get it right :)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

Thank you so much for you nice advice. One thing else I need to ask
that is knowing tcl important in VHDL design and coding?

And is it same as TCL in Unix?


Regards,
ak


On Sep 4, 2:41 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Tue, 04 Sep 2007 00:51:27 -0700, Amit <amit.ko...@gmail.com> wrote:
Does anybody know how should I a newibe like me can get started on
VHDL and Image Processing?

I have purchased Altera DE2.

The obvious Google search will bring up lots of hits, but first
I suggest you should concentrate on getting the basics in place.
I don't know the Altera DE2 board, but whatever, make sure you
know how to get an image into its on-board memory, and how to
display that image on a monitor of some kind. Once you've done
that, consider doing some REALLY simple operation on every pixel
in the image - for example, make the image negative - and check
that works by simply looking at the displayed result.

Having done those things, you are probably ready to do some
more interesting image processing operations. First, try to
implement a 3x3 moving-average filter over the image - for
each pixel, compute the average of that pixel and its eight
immediate neighbours, and use that average as the output
pixel value. Again your success or failure can easily be
confirmed by inspection of the displayed image, and it's
a good way to start thinking about the addressing issues
(how do you access a pixel's near neighbours?).

Now you're ready to do just about any of the classic image
processing operations such as edge detection, contrast
enhancement and so on; you can start concentrating on the
image processing problems, because you will by then
understand how to implement it in the FPGA. It should also
be an easy step from there to doing image compression tasks
like DCT.

The next step is to start considering geometrical operations
such as rotation and scaling. These tend to be quite a bit
harder in FPGAs because they need complicated address
calculations that don't have the simple locality that you
find with filtering operations.

Depending on what peripheral hardware you have with your
development board, you may or may not be able to implement
these operations in real-time on a video stream. If so,
you can then consider operations *between* images, rather
than *within* a single frame; that step allows you to do
stuff like motion estimation as well as some interesting
compression and noise-reduction tricks. But it will
require you to manage quite a lot of memory.

I think that the message I'm trying to convey is this:
Image processing on an FPGA is, in principle, no different
than image processing in software. However, the very
different resources on an FPGA compared with a software
platform mean that the main practical difficulties are
likely to be issues like memory access and video interfacing,
rather than the theory of the image processing itself.
Your reward for mastering those difficulties, of course,
will be astonishingly high throughput - if you get it right :)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Tue, 04 Sep 2007 18:17:00 -0000, Amit wrote:

is knowing tcl important in VHDL design and coding?
And is it same as TCL in Unix?
EVERY significant simulation and synthesis tool has Tcl
as its scripting language, or offers Tcl as one option
for scripting. So, yes, it is very helpful indeed to
know Tcl - although many people successfully design
and simulate without any deep knowledge of Tcl,
because the tools' GUIs often help you to do the
same tasks that you might otherwise do in Tcl.

If you wish to manage external data files (such as
image files) in your VHDL simulations, then Tcl is
definitely your friend, because VHDL's facilities for
file management are quite weak.

One of the really, really cool things about Tcl is
the way it is completely platform-independent: Unix,
Windows, Mac - it's all the same.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Tue, 04 Sep 2007 18:17:00 -0000, Amit <amit.kohan@gmail.com> wrote:
Hello Jonathan,

Thank you so much for you nice advice. One thing else I need to ask
that is knowing tcl important in VHDL design and coding?

And is it same as TCL in Unix?
Tcl seems to be quite common in EDA (perhaps because it was originally
developed to produce an EDA tool).

The Tcl language is standard, you just have to learn the extra functions
that the vendor has added.

A bientot
Paul
(Not speaking for Mentor Graphics)
 
On Tue, 04 Sep 2007 21:11:53 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Tue, 04 Sep 2007 18:17:00 -0000, Amit wrote:

is knowing tcl important in VHDL design and coding?
And is it same as TCL in Unix?

EVERY significant simulation and synthesis tool has Tcl
as its scripting language, or offers Tcl as one option
for scripting.
Even XST? If XST offered TCL scripting I'd be very happy.

Regards,
Allan
 
On Wed, 05 Sep 2007 15:45:56 +1000, Allan Herriman
<allanherriman@hotmail.com> wrote:

On Tue, 04 Sep 2007 21:11:53 +0100, Jonathan Bromley
jonathan.bromley@MYCOMPANY.com> wrote:

EVERY significant simulation and synthesis tool has Tcl

Even XST? If XST offered TCL scripting I'd be very happy.
oops, another example of the only inviolable rule of Usenet:
never state an inviolable rule on Usenet :)

Yes, I think you're right; I confess I've never done much
scripting of XST.

Apologies.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
"Allan Herriman" <allanherriman@hotmail.com> wrote in message
news:vhgsd3dr1gt7661olj043g0q14oq7vsv37@4ax.com...
On Tue, 04 Sep 2007 21:11:53 +0100, Jonathan Bromley
jonathan.bromley@MYCOMPANY.com> wrote:

On Tue, 04 Sep 2007 18:17:00 -0000, Amit wrote:

is knowing tcl important in VHDL design and coding?
And is it same as TCL in Unix?

EVERY significant simulation and synthesis tool has Tcl
as its scripting language, or offers Tcl as one option
for scripting.

Even XST? If XST offered TCL scripting I'd be very happy.
He said significant... no just kidding:) You can always install tcl
(http://www.activestate.com/Products/ActiveTcl/) and call XST from the tclsh
shell(if {[catch {exec xst.exe ....} results]}). You can then use Tcl to
modify/create the XST input command file before calling XST.

Just a thought,
Hans
www.ht-lab.com



Regards,
Allan
 
On Wed, 05 Sep 2007 09:12:56 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Wed, 05 Sep 2007 15:45:56 +1000, Allan Herriman
allanherriman@hotmail.com> wrote:

On Tue, 04 Sep 2007 21:11:53 +0100, Jonathan Bromley
jonathan.bromley@MYCOMPANY.com> wrote:

EVERY significant simulation and synthesis tool has Tcl

Even XST? If XST offered TCL scripting I'd be very happy.

oops, another example of the only inviolable rule of Usenet:
never state an inviolable rule on Usenet :)

Yes, I think you're right; I confess I've never done much
scripting of XST.
I think it's new with ISE 9.1 or 9.2, but there is a "TCL shell" tab in
Project Navigator, or you can apparently run TCL scripts through
"xtclsh" at the command line.

I don't know how deep inside XST itself you can delve with TCL
scripting, but it's there for basic tool flows (it even builds a large
script to recover a project after a crash).

I haven't played around with it much, so I haven't found a way to
capture what I do through the GUI in TCL form, to save it, clean it up
in an editor, and replay it later.

I don't consider myself a TCL guy, but I've found that capability very
useful in Modelsim, to experiment first, and repeat tests consistently
later.

- Brian
 

Welcome to EDABoard.com

Sponsor

Back
Top