Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
- From: rickman <gnuarm@xxxxxxxxx>
- Date: Thu, 05 Jul 2007 09:06:40 -0700
On Jun 24, 11:45 am, wilco.dijks...@xxxxxxxxxxxx wrote:
On 23 Jun, 03:10, rickman <gnu...@xxxxxxxxx> wrote:
I don't follow what you are saying at all. Branch prediction relates
to pipelining. I don't see how it relates to wait states.
Adding a wait state is the same as increasing the pipeline depth, and
branch
prediction coupled with prefetching can hide some of that latency.
I don't see how that is true at all. When you add a waitstate you
freeze all stages of the pipeline while you wait for the Flash to
finish the access.
You have to increase the fetch width if you add waitstates, that's a
given. The
M3 TRM recommends 64-bit flash fetch. While this allows straightline
code to run
at full speed, branches are still slow. What I meant is that M3 has
branch
optimizations that reduce this slowdown.
I don't have the option of increasing the width of the Flash.
Besides, you statement is just plain wrong. If you add waitstates,
the Flash width is not relevant. If you increase the Flash width, you
can use fewer wait states, but that is entirely different from what
you are saying. What did you mean to say?
power
consumption at lower speeds. The specs showed various settings that
use
significantly less than 9mA below 8MHz. So I don't think it really
burns 9mA
at 0MHz (which is what I think you mean with Y intercept, right?).
Sure, if you want to turn off the flash entirely you can get the power
down, or if you want to stop the clocks you can get the power down.
My point is that under normal operating conditions, the part has a
hefty static power consumption so that running at half speed does not
get you near half current. Still, it is a lot better than the
Luminary parts, but not so near the Atmel ARM7 parts.
The ST specs list some numbers with peripherals off, and that is less
than
half the normal current, 21mA from flash at 72MHz IIRC - pretty good.
I don't see that figure anywhere. What page did you read this?
Regardless, if they are doing things to reduce power consumption, like
running from RAM, then the comparison is still not apples to apples.
It just depends on what you want to compare.
How do you support the claim that the M3 runs twice as fast as the
SAM7 at the same frequency??? Maybe I don't want to know...
Because I've benchmarked it myself?
Ok, has anyone else on the planet published similar results? I have
not even heard anyone else make this claim, much less be able to
support it.
You seem to forget that the M3 was designed from the ground up to be
an efficient
MCU, while ARM7 wasn't:
I'm not even considering that. I am reporting what I have read as
measured results. But then I don't know of any published benchmarks.
I guess that is what is required.
Yes, but that is a small delta compared to adding waitstates with a 2x
or 3x reduction in performance and therefore the same effect on power
efficiency.
Not at all. Adding waitstates doesn't slow you down by that much as
you make
the memory wider (not doing that makes no sense at all, so I do not
consider
that a valid option). But instruction set and microarchitecture
differences can easily
make a factor of 2 difference, as shown above.
How do you make the memory wider? I would love to be able to do that
with a lot of the MCU chips I have used in the past. Can you use this
Flash stretcher tool on Atmel parts as well? Then they could run at
55 MHz with no wait states!!!
.
- Follow-Ups:
- Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
- From: Ulf Samuelsson
- Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
- Prev by Date: AT91RM9200 Lauterbach JTAG effect on Ethernet
- Next by Date: Re: hc12 sci PROBLEM
- Previous by thread: Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
- Next by thread: Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
- Index(es):
Relevant Pages
|
