Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics



On Jul 6, 10:51 am, "Ulf Samuelsson" <u...@xxxxxxxxxxxxx> wrote:
The FIFO is implemented using Flip-Flops and you had a
simple three stage pipeline (fetch, decode,execute) so
your latency was not dramatic.

That is not the point. By prefetching the instructions, you are
setting up for a bigger dump and subsequent loss of instruction memory
bandwidth when you branch. FIFOs or instruction prefetching are not a
perfect solution. It is much better to just have single cycle
memory.


If you have one waitstate, you will see that the bandwidth is still high
Yes, but if the jumps are probably only 10-20% of all instructions
so you lose only between 10-20% of the performance instead of 50%.
The AVR32 loses less than 10% in average.

But you are comparing apples and oranges. A processor that has no
wait states doesn't have to deal with this no matter what the
instruction mix is. It is just much simpler to not have to consider
memory latencies.


I have run the SAM7 at 48 MHz, zero waitstate. Does not work over the
full
temp range though.
The AVR32 will support 1.2 MIPS/MHz @ 1 waitstate operation @ 66 MHz
due to its 33 MHz 2 way interleaved flash memory.
(1st access after jump is two clocks, subsucquent accesses are 1 clock)

How does that compare to the Cortex M3 running at 50 MHz with no
waitstates and no branch penalty?

The UC3000 is claimed as 80 MIPS at 66 MHz.
For the Cortex M3 to reach 80 MIPS at 50 MHz,
you have to have 80/50 = 1,6 MIPS per MHz.
I think that ARM does not claim that the Cortex is close to 1,6 MIPS per
MHz.

Oh, this is marketing stuff. I thought you might have run some real
benchmarks or someone else at Atmel might have. Certainly they have
looked hard at the Cortex. But if it competes too well against the
AVR32, I can see why it would not be pushed at Atmel. Certainly there
will be a lot of sockets that will be won by an ARM device over a sole
source part like the AVR32. At this point I don't think anyone can
say whether the AVR32 has legs and will be around in 5 years. It has
been out for what, a year or so?


The AVR32 is decidedly better on DSP algorithms due to its
single cycle MAC and also it has faster access to SRAM.
Reading internal SRAM is a one clock cycle operation on the AVR32.
Bit banging will be one of the strengths of the UC3000.

Isn't reading internal SRAM a single cycle on *all* processors? I
can't think of any that require wait states. In fact, most processors
try to cram as much SRAM onto the chip as possible because it is so
fast. Did you say what you meant to say?


.



Relevant Pages

  • Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
    ... setting up for a bigger dump and subsequent loss of instruction memory ... For the Cortex M3 to reach 80 MIPS at 50 MHz, ... AVR32, I can see why it would not be pushed at Atmel. ...
    (comp.arch.embedded)
  • Re: [PATCH v2 2/6] mips dynamic function tracer support
    ... I have one question about dynamic ftrace support for modules on mips arch. ... We know that on mips, kernel symbol will locate in 0x80000000~0x90000000, and modules' symbol will locate in>0xc0000000. ... kernel should relocate "jal 0" instruction to jump to the ...
    (Linux-Kernel)
  • Re: AVR32 availablilty ?
    ... Whether a core has a divide or a MAC ... instruction is not as relevant as the ability to run real world code ... Just do a series of MACs where you check for saturation and the AVR32 ... There is a difference between DSP "operations" and DSP ...
    (comp.arch.embedded)
  • Re: Doubt reg MIPS Vs MHz
    ... >>>Is there a way to calculate MIPS from MHz ?? ... >> execute several instructions in one clock cycle. ... >> clock cycles to perform one instruction. ... effectively doubles the computation power of the DSP when executing code ...
    (comp.dsp)
  • Re: Processors whos stack grows up
    ... of returning from subroutines was by forming a linked list. ... modern primitive instruction set micros as MIPS. ... * The early Burroughs machines are a must see: ...
    (comp.arch.embedded)