everphilski@gmail.com wrote:

> Rob,
> 
> On Feb 13, 4:18 am, Rob <BertyBoos...@googlemail.com> wrote:
> 
>>>Xilinx's FireBlaze processor simulation on a FPGA.
>>
>>Do you mean Xilinx's MicroBlaze processor? If so, note that this is a
>>general purpose CPU with a fairly average MIPs spec. You'd easily be
>>able to get comparable or better performance with an off the shelf
>>microprocessor -and without all the headaches!
> 
> 
> Yes, I meant MicroBlaze, thanks for catching the typo. This is good,
> so you are saying you would prefer working with a discrete
> microcontroller interfaced to a FPGA, instead of a FPGA with a
> MicroBlaze (or other core) onboard?

PFGA+MicroBlaze lacks code memory, so that's a significant cost.
Generally, if you can find a single chip uC that will fit your task,
you get the EMC & reliability benefits of on-chip memory, and
also (probably) get to use a smaller/cheaper FPGA+LoaderPROM

A good topical example of a companion processor for FPGA,
would be the Atmel AT91SAM9XE series. 200+ MIPS, from 128 bit wide
flash, and $7.30/10K, with 128/256/512K FLASH.

Plus all this fruit:
[USB 2.0 Full Speed Host and Device Ports, an Ethernet 10/100 Base-T MAC 
as well as a two-slot Multimedia Card Interface (SDCard/SDIO and 
MultiMediaCard Compliant), a Synchronous Serial Controller (SSC), four 
USARTs, two master/slave Serial Peripheral Interfaces (SPI), a debug 
UART and two Two Wire Interfaces (TWI).]

If you need megabytes of code, then the balance tips back a little.

-jg

everphilski@gmail.com <everphilski@gmail.com> wrote:
> Could I get you to expand on the difference between "DSP hardware" and
> "FPGA" in this context? My (albeit new) understanding was, DSP
> techniques were implemented on FPGA hardware to do digital signal
> processing.

Well, first of all, DSP is probably the topic of yours that I know the
least about so take anything I say with a couple grains of salt.

When I personally think DSP, what comes to mind are things like the 
TI DSP processors which were/are more like general purpose CPUs with
an emphasis on high-speed fixed- or floating-point math rather than
being a general purpose "sea of gates" as an FPGA is.  TI has some
introductory info here it looks like:

   http://focus.ti.com/dsp/docs/dspsupporto.tsp?sectionId=4&tabId=1443

Modern FPGAs have some of the basic building blocks (interger multiply
units, etc.) that make it possible to do traditional DSP processing, 
but you're still mostly building up a machine from scratch to do what
you want rather than just writing a program to express an algorithm.

I don't think it's always easy to answer the question of what should
be done in hardware versus software.  Often there are techniques to
do it either way, and the background of the particular designer tends
to tilt the decision more than anything else.

FPGAs are incredibly cool.  They're great when you need boatloads of
exotic I/Os, extreme parallelism, and complete flexibility.  They don't
make great general purpose CPUs usually.  From a software point of view
they're again the most flexible but probably also the most complex.
From a hardware point of view they're pretty much all cutting-edge 
technology and none of their design is there to make the life of a
hobbyist easy, so building your own FPGA-based hardware designs is 
pretty complex.  Fortunately there are lots of inexpensive boards
you can buy to experiment with.

If you pick up an FPGA board to play with and spend some time with 
it then I don't think you'll regret that learning experience at all.
Whether at the end you decide that the FPGA route is your best one
for implementing the things you want to do is something you'll only
know once you get there.

G.

On Wed, 13 Feb 2008 07:56:57 -0800 (PST), everphilski wrote:

>> For robotics I think you're better off in the microcontroller realm,
>> with something like your Amtel AVR or a Parallax Propeller that will
>> easily interface with all kinds of easily available and relatively
>> inexpensive modules (www.sparkfun.comkinda stuff).  I think of
>> robotics more as a system integration problem.
>>
>
>I'd tend to agree with you, it's an integration problem. I was trying,
>I guess, to come up with a good excuse to learn FPGA's and then DSP
>techniques.

Depending on what sort of hardware you expect to have for
your robotics, FPGAs can actually be pretty neat for the
very low-level interfacing stuff.  Standard mechatronics
functions such as quadrature-encoder counters, PWM motor
drivers and so forth go nicely into FPGAs, and the digital
design is relatively straightforward so you can concentrate
on the FPGA-specific aspects.  Because you have an FPGA to
play in, you're not locked to the limitations of software
(response speed? time resolution?) and you're not limited
by what a specific device manufacturer chooses to build
and sell - so, for example, it's easy to make encoder
counters that automatically latch the count value at the
moment of an index pulse, so that your s/w can interrogate
that latched value at leisure; encoder counters with some
built-in timed interpolation or velocity measurement;
unusual PWM structures to meet specialised needs; 
programmable triggering of external outputs when an 
axis reaches a preset position...  Lots of stuff like
that, which is tiresome to do in software - and probably
near-impossible to do with microsecond time resolution.
In some ways it's a waste of an FPGA, but hey, the thing
is sitting there waiting for you to do something with it...

Just don't forget to think about the electrical robustness
of connections to the FPGAs.  Modern FPGAs have fairly 
feeble I/O structures [*] working at 3V or less, and they 
don't take kindly either to >5V external connections, or 
to the kind of unpleasant electromagnetic crud that 
tends to come for free with anything electromechanical.
Much care with level shifters, buffers and snubber
circuitry is needed to protect your FPGA investment.
The nice folk at sci.electronics.design will likely be
pretty helpful about that sort of thing, and will be
up-to-date with what's available to make it easier.

[*] Feeble by the standards of industrial automation.
    No slight on the FPGA manufacturers intended!
-- 
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.

Gavin,

On Feb 12, 7:18 pm, ga...@allegro.com (Gavin Scott) wrote:
> everphil...@gmail.com <everphil...@gmail.com> wrote:
> >  I'm interested in learning more about DSP's and actually getting my
> > feet wet with DSP hardware. I have three primary interests:
> > 1) robotics
>
> For robotics I think you're better off in the microcontroller realm,
> with something like your Amtel AVR or a Parallax Propeller that will
> easily interface with all kinds of easily available and relatively
> inexpensive modules (www.sparkfun.comkinda stuff).  I think of
> robotics more as a system integration problem.
>

I'd tend to agree with you, it's an integration problem. I was trying,
I guess, to come up with a good excuse to learn FPGA's and then DSP
techniques. I have a lot of ideas, but robotics is something I
actually have practical experience in so I figured I could sub out the
FPGA for the AVR/MC68HC11/PIC's I've used in the past as a learning
experience, before going on to other projects like vision processing
and radio processing where I know very little and I'd have to learn
more than just the FPGA design aspects. That was my thought.

> > 3) software defined radios.
>
> For SDR maybe some DSP hardware (or FPGA maybe, though I'm not sure
> how much fun doing serious DSP in a Spartan 3 would really be) probably
> makes sense.  I think there might be a few reasonably priced
> experimenter's boards out there.
>

Could I get you to expand on the difference between "DSP hardware" and
"FPGA" in this context? My (albeit new) understanding was, DSP
techniques were implemented on FPGA hardware to do digital signal
processing. Or are you talking about a chip tailored specifically to
audio processing versus a general purpose FPGA?

> FPGAs are pretty cool, especially the "hardware becomes software" aspect
> which is quite appealing to those of us with more of a software
> background, but they're also very complex so if you're really interested
> in learning to design for FPGAs (programming in VHDL/Verilog etc.)
> then great, but if you're more interested in the applications than
> in the technology then something less generic and more specific to
> the problem you're trying to solve might greatly simplify things.
>

I am interested in learning. I do have experiance with various
microcontrollers and I write various simulations/data reduction codes
at work, but nothing in real time like a DSP would perform. It kind of
sounds like fun.

> Just my random thoughts.
>

I do appreciate them, thank you.

> G.

Philip

Rob,

On Feb 13, 4:18 am, Rob <BertyBoos...@googlemail.com> wrote:
> > Xilinx's FireBlaze processor simulation on a FPGA.
>
> Do you mean Xilinx's MicroBlaze processor? If so, note that this is a
> general purpose CPU with a fairly average MIPs spec. You'd easily be
> able to get comparable or better performance with an off the shelf
> microprocessor -and without all the headaches!

Yes, I meant MicroBlaze, thanks for catching the typo. This is good,
so you are saying you would prefer working with a discrete
microcontroller interfaced to a FPGA, instead of a FPGA with a
MicroBlaze (or other core) onboard?

Thanks,

Philip

> Xilinx's FireBlaze processor simulation on a FPGA.

Do you mean Xilinx's MicroBlaze processor? If so, note that this is a
general purpose CPU with a fairly average MIPs spec. You'd easily be
able to get comparable or better performance with an off the shelf
microprocessor -and without all the headaches!

gavin@allegro.com (Gavin Scott) writes:

> everphilski@gmail.com <everphilski@gmail.com> wrote:
>>  I'm interested in learning more about DSP's and actually getting my
>> feet wet with DSP hardware. I have three primary interests:
>
>> 1) robotics
>
> For robotics I think you're better off in the microcontroller realm,
> with something like your Amtel AVR or a Parallax Propeller that will
> easily interface with all kinds of easily available and relatively
> inexpensive modules (www.sparkfun.com kinda stuff).  I think of 
> robotics more as a system integration problem.

The Propeller is interesting, it'll certainly get you thinking
parallel which will stand you in good stead for FPGAs (and for future
processors!)

>
>> 2) computer vision
>
> Machine vision is pretty much entirely a software issue I think, 

You may think so - I'd disagree!  Machine vision is an *algorithms*
thing.  Algorithms are often easiest to prototype in SW at a desk with
a webcam, but if you want to make them run "standalone" then
targetting an FPGA for the highly parallel parts makes a lot of
sense.  Of course, to do that successfully, you have to build your
algorithms with FPGAs in mind - and to do that, you have to have tried
to implement some already :-)

> so if you want to learn about it, I'd consider starting with a PC
> and a $20 webcam and the free programming language of your choice
> along with a book or two on the subject.

Agreed! But if you *ever* want it to run outside of a PC, run around
the loop of "taking the algorithms into embedded hardware and changing
them to suit" early and lots of times.  You'll learn more that way.

>>  My second question is, what is the best way to start learning? In
>> doing reading I see the Spartan 3E evaluation board seems to be highly
>> recommended. The board looks neat, I'm just curious what the best way
>> to learn is.
>
> The Spartan 3 starter board is fine (I have one), but to get started
> and get a feel for things you can start by downloading the free ISE
> WebPack software from Xilinx to see what the development process looks
> like for their FPGAs.  You can design/code, build and simulate all
> without actually having any actual hardware.

Yeah, but it's much more fun when you can see that LED flashing like
you told it to instead of a wiggly waveform on screen :-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

everphilski@gmail.com <everphilski@gmail.com> wrote:
>  I'm interested in learning more about DSP's and actually getting my
> feet wet with DSP hardware. I have three primary interests:

> 1) robotics

For robotics I think you're better off in the microcontroller realm,
with something like your Amtel AVR or a Parallax Propeller that will
easily interface with all kinds of easily available and relatively
inexpensive modules (www.sparkfun.com kinda stuff).  I think of 
robotics more as a system integration problem.

> 2) computer vision

Machine vision is pretty much entirely a software issue I think, so
if you want to learn about it, I'd consider starting with a PC and a
$20 webcam and the free programming language of your choice along
with a book or two on the subject.  Learning how to design a solution
and implementing that solution in something like an FPGA are probably
quite different tasks, and I'd be afraid of drowning in the details
of implementation while trying to learn how to design what you want.

> 3) software defined radios.

For SDR maybe some DSP hardware (or FPGA maybe, though I'm not sure
how much fun doing serious DSP in a Spartan 3 would really be) probably
makes sense.  I think there might be a few reasonably priced 
experimenter's boards out there.

>  My second question is, what is the best way to start learning? In
> doing reading I see the Spartan 3E evaluation board seems to be highly
> recommended. The board looks neat, I'm just curious what the best way
> to learn is.

The Spartan 3 starter board is fine (I have one), but to get started
and get a feel for things you can start by downloading the free ISE
WebPack software from Xilinx to see what the development process looks
like for their FPGAs.  You can design/code, build and simulate all
without actually having any actual hardware.

FPGAs are pretty cool, especially the "hardware becomes software" aspect
which is quite appealing to those of us with more of a software
background, but they're also very complex so if you're really interested
in learning to design for FPGAs (programming in VHDL/Verilog etc.)
then great, but if you're more interested in the applications than
in the technology then something less generic and more specific to
the problem you're trying to solve might greatly simplify things.

Just my random thoughts.

G.

<everphilski@gmail.com> wrote in message 
news:80dca10c-c80d-4fa2-9ed5-0ba73bc161fa@s37g2000prg.googlegroups.com...
>
> I'm wondering if it would be more practical to build robotics around the
> FPGA from square one and start learning now. It seems like you can do
> just about anything with FPGA's (with some tradeoffs of course)

I think it depends on whether your goal is to build a robot or to learn 
something completely new and not much related to robots. Yes, you can do 
many different things with FPGAs, but if you want to build a robot soon 
choose the path you already know...

/Mikhail 

>...what is the best way to start learning? In
>...I'm just curious what the best way to learn is.
>
> I'm doing this as a hobby...a mechanical engineer by trade.
>I've been programming C/C++ for 10 years...
>"I know enough to be dangerous". :)

There's no "royal road" to learning.  If you're a genius then you can
maybe learn just by reading textbooks.  For the rest of us, just start
anywhere and see where it takes you.  Doing this as a hobby gives you
the luxury of taking any road you fancy, but omits the discipline of a
goal you can't change.  My own preference is for that unyielding
target, but that may not be best for everyone.

If you're very rich then send yourself on training courses, but you'll
still have to put in hard work and late nights to become competent.

The first step to that competence is knowing that you know enough to
be dangerous.  This puts you ahead of many who, after ten years of
"professional" work don't realise that they're still dangerous.

Mike