How to compare computing power of microcontrollers?

Hi - I'm trying to choose a microcontroller for a project I'm working
on. Originally I had been thinking about using a 20Mhz Atmel AVR, such
as an ATMEGA168, but I became worried about the raw computing power of
the AVR, as one of the main roles of this chip will be to do alot of 16
bit multiplication and trig at a fairly high speed. So I've been
looking at using an ARM - specifically the Atmel AT91SAM7A3 looks very
interesting to me. It's clocked 3 times as fast as the ATMEGA168, but I
expect that isn't a good way at all to compare it's ability to handle
this task to the AVR's. Is there any good way to make a comparison for
this application without benchmarking the chips? Thanks,

-Michael J. Noone

Michael J. Noone wrote:
> Hi - I'm trying to choose a microcontroller for a project I'm working
> on. Originally I had been thinking about using a 20Mhz Atmel AVR, such
> as an ATMEGA168, but I became worried about the raw computing power of
> the AVR, as one of the main roles of this chip will be to do alot of 16
> bit multiplication and trig at a fairly high speed. So I've been
> looking at using an ARM - specifically the Atmel AT91SAM7A3 looks very
> interesting to me. It's clocked 3 times as fast as the ATMEGA168, but I
> expect that isn't a good way at all to compare it's ability to handle
> this task to the AVR's. Is there any good way to make a comparison for
> this application without benchmarking the chips? Thanks,
> 
> -Michael J. Noone


ARM is also a 32 bit CPU, vs. 8 bits for the AVR.  So for instance, to 
do 32 bit arithmetic operations on AVR takes 4 instructions/clocks, 
while the ARM will do a 32 bit operation in one instruction/clock.

For floating point stuff, things are more complicated, but still the 
advantage goes to the 32-bit CPU.

So for 32-bit integer arithmetic anyway, a 60MHz ARM would be roughly 12 
times faster than an AVR.


-- 
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

On 2005-08-30, Chris Carlen <crcarleRemoveThis@BOGUSsandia.gov> wrote:
> Michael J. Noone wrote:
>> Hi - I'm trying to choose a microcontroller for a project I'm working
>> on. Originally I had been thinking about using a 20Mhz Atmel AVR, such
>> as an ATMEGA168, but I became worried about the raw computing power of
>> the AVR, as one of the main roles of this chip will be to do alot of 16
>> bit multiplication and trig at a fairly high speed. So I've been
>> looking at using an ARM - specifically the Atmel AT91SAM7A3 looks very
>> interesting to me. It's clocked 3 times as fast as the ATMEGA168, but I
>> expect that isn't a good way at all to compare it's ability to handle
>> this task to the AVR's. Is there any good way to make a comparison for
>> this application without benchmarking the chips? Thanks,
>> 
>> -Michael J. Noone
>
>
> ARM is also a 32 bit CPU, vs. 8 bits for the AVR.  So for instance, to 
> do 32 bit arithmetic operations on AVR takes 4 instructions/clocks, 
> while the ARM will do a 32 bit operation in one instruction/clock.
>
> For floating point stuff, things are more complicated, but still the 
> advantage goes to the 32-bit CPU.
>
> So for 32-bit integer arithmetic anyway, a 60MHz ARM would be roughly 12 
> times faster than an AVR.

At least.  Rember the ARM has a barrel-shifter that can be used
in "parallel" with an arithmetic operation.  IOW,

  A = A + B<<3;

Is a single instruction on an ARM.  If A and B are 32-bit ints,
I doubt that can be translated into to 4 AVR instructions.

-- 
Grant Edwards                   grante             Yow!  I just remembered
                                  at               something about a TOAD!
                               visi.com            

If you don't have hardware for both, I would write a piece of assembly
code "on paper". This code should be represntative of a function that
you will be doing for your application (ie. 16 bit multiplication and
trig). And add up the number of clock cycles it would take each
processor to run the same piece of code.

This calculations assumes each processor has similar instructions and
the compilers you use have a similar optimization routine.

You know the # of clock cycles and the frequency, you can then evaluate
which processor has a better performance for your application.

It is time consuming, but without looking at the Datapath / Instruction
cycles you can't evaluate the performance.

Example: a processor may run at a  faster clock frequency, but if the
instructions you are using aren't pipelined well your just burning up
power and not gaining performance.

Multiplication tends to be one of the instructions that is poorly
pipelined in smaller cpus. So the # of instructions that MULT takes
might be a good enough benchmark for your application.

Good Luck,
Eric

On 30 Aug 2005 09:01:28 -0700, the renowned "Eric"
<ericjohnholland@hotmail.com> wrote:

>If you don't have hardware for both, I would write a piece of assembly
>code "on paper". This code should be represntative of a function that
>you will be doing for your application (ie. 16 bit multiplication and
>trig). And add up the number of clock cycles it would take each
>processor to run the same piece of code.
>
>This calculations assumes each processor has similar instructions and
>the compilers you use have a similar optimization routine.
>
>You know the # of clock cycles and the frequency, you can then evaluate
>which processor has a better performance for your application.
>
>It is time consuming, but without looking at the Datapath / Instruction
>cycles you can't evaluate the performance.
>
>Example: a processor may run at a  faster clock frequency, but if the
>instructions you are using aren't pipelined well your just burning up
>power and not gaining performance.
>
>Multiplication tends to be one of the instructions that is poorly
>pipelined in smaller cpus. So the # of instructions that MULT takes
>might be a good enough benchmark for your application.
>
>Good Luck,
>Eric

IIRC, the AVR has an 8 x 8 multipler, wheras the ARM core has a wider
multiplier (32 x 8?) and microcode to do 32 x 32 multiplies. By the
time you assemble all the partial products with the AVR, the
difference in speed might be quite large for multiply. 

Personally, I'd write a little chunk or two of code and simulate it. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Eric wrote:

> If you don't have hardware for both, I would write a piece of assembly
> code "on paper". This code should be represntative of a function that
> you will be doing for your application (ie. 16 bit multiplication and
> trig). And add up the number of clock cycles it would take each
> processor to run the same piece of code.
> 
> This calculations assumes each processor has similar instructions and
> the compilers you use have a similar optimization routine.
> 
> You know the # of clock cycles and the frequency, you can then evaluate
> which processor has a better performance for your application.
> 
> It is time consuming, but without looking at the Datapath / Instruction
> cycles you can't evaluate the performance.
> 
> Example: a processor may run at a  faster clock frequency, but if the
> instructions you are using aren't pipelined well your just burning up
> power and not gaining performance.
> 
> Multiplication tends to be one of the instructions that is poorly
> pipelined in smaller cpus. So the # of instructions that MULT takes
> might be a good enough benchmark for your application.

Good advice from Eric there. You should also be aware of the cost 
constraints of your project (is this a one off or do you need to make 
millions of devices?). This will also determine whether the effort you 
expend in finding the processor is better than going wity one that may be 
overkill in terms of obvious performance advantage.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

"So for instance, to
do 32 bit arithmetic operations on AVR takes 4 instructions/clocks,
while the ARM will do a 32 bit operation in one instruction/clock. "

I would think its more like a 12-1 ratio, 32 bit add on a 8 bit machine
generally requires loads and stores inbetween each 8 bit add

http://www.keil.com/benchmks/tm_c51_v7_small.asp

Don't know about AVR's but the above is a good site to compare the
differences between processing power between 8051 and ARM's, it allows
you to type in the frequency of each part and it will show you how long
a 8,16 or 32 bit add/sub/mul will take as well as float trig functions.