6
\$\begingroup\$

Currently when I work with microcontrollers, I use Microchip PICs and I'm happy enough with them. However, I decided to just take a look at ARM for a possible upcoming project. I wanted the pick the best (fastest at calculations at the cheap/low-power end) ARM. On the ARM website(here), the Cortex M0+ is listed at 2.46 CoreMark/MHz. I thought that CoreMark rating would apply to all microcontrollers with M0+ cores but on the Atmel SAM D20 page the microcontroller is listed as having 2.14 CoreMark/MHz. I read on some websites that the compiler affects the CoreMark score. I have also seen websites list an M0+ as having 1.77 CoreMark/MHz without talking about a compiler (element14). I also noticed ARM talks about the M0+ on a 40LP process while the element14 site talks about the ARM on a 90LP process. Unfortunately I am not knowledgeable about chip scale processor manufacturing.

So my questions are;

  1. Do variants of the M0+ processor core exist? If yes, how do you spot which is which?
  2. If programmed by assembly language, would all microcontrollers with ARM Coretex M0+ cores have the same CoreMark rating?

By the way, the micro I intend to use is of the MKL03Z family. Any more info would be appreciated.

Thanks!

\$\endgroup\$
  • \$\begingroup\$ Google: infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0350a/…. It is fairly obvious from TFM that this is a benchmarking of the CPU plus the toolchain. The compiler's ability to optimize and what optimizer settings that are used will have much greater impact than various core features implemented. \$\endgroup\$ – Lundin Sep 27 '17 at 9:04
7
\$\begingroup\$

Short answer:

  1. Yes
  2. No

Long answer:

ARM cores have features that each manufacturer may or may not decide to implement (e.g. caches, bus fetch width, FPU, MPU, etc. - of course the availability depend on the type of core e.g. 7xx, 9xx, M0, M0+, M3, M7, etc.).

Having or not some feature will impact the CPU performance.

The following image is taken from the SAMD21 datasheet. As you can see they decide to implement a fast multiplier and a 32-bit fetch width. This probably allowed the SAMD21 to reach a 2.46 CoreMark/MHz figure.

enter image description here

The datasheet states:

The SAM D21 devices operate at a maximum frequency of 48MHz and reach 2.46 CoreMark/MHz

(By the way, the SAMD20 also states that it can reach that figure, and not just 2.14).

The SAM D20 devices operateat a maximum frequency of 48MHz and reach 2.46 CoreMark®/MHz.

If you programmed in ASM two different Cortex M0+, featuring different options (e.g. one has slow multiplier and 16-bit bus instruction fetch width, and the other has a fast multiplier and 32-bit fetch width), then the results would be different. Results would also be different if the test runned on memories with different access times.

Also, the Coremark results, found on the Coremark website, specify the compiler version (and flags used to compile the test). Therefore they are also compiler dependent.

\$\endgroup\$
  • 1
    \$\begingroup\$ You can find the configurable options direct from ARM here in section 1.4. For what it's worth, I was told by one of their engineers that Atmel/Microchip generally implement everything that ARM offers. \$\endgroup\$ – Spehro Pefhany Sep 22 '17 at 17:31
  • 1
    \$\begingroup\$ Thanks for the comment @SpehroPefhany . I followed the link to read it. Just a slight correction, that links to the M0 core configuration. The M0+ core configuration is here Thanks! \$\endgroup\$ – Alaba Baju Sep 22 '17 at 19:24
  • 1
    \$\begingroup\$ next-hack Thanks, that was a good explanation and thanks for pointing out the configuration table too :) @SpehroPefhany I wish Freescale(NXP) were as clear as Microchip as to what they did and did not implement. The Freescale micros are so cheap! I've been able the find out the MKL03Z does single cycle 32bit multiply though. \$\endgroup\$ – Alaba Baju Sep 22 '17 at 19:32
  • \$\begingroup\$ @SpehroPefhany. Thank for the anecdote! So maybe that's why, for instance, SAME7 has such high level features, with respect to other cortex M7 from competitors. \$\endgroup\$ – next-hack Sep 23 '17 at 7:53
6
\$\begingroup\$

I am not aware of variants of the m0+ core, but different chips will have different memory bus connections and FLASH controllers. FLASH memory is typically too slow to keep up with modern microcontrollers. Most microcontrollers will feature FLASH accelerators to speed up sequential access. However on random access, like a jump or branch, there could be multiple wait cycles involved.

This could mean that the controller can reach a higher Coremarks/MHz figure when the controller is being run at a lower clock speed. Of course, the processor at a higher clock speed will complete more calculations, just saying there could be more wait states involved at higher clocks. Some microcontrollers have very good FLASH accelerators though that there are almost zero wait states.

Moreover, some microcontrollers may have enough SRAM space & blocks to run the benchmark from SRAM. This could be faster if there is no contention with data access. Likely ARM will test with this technique, as they are interested in benchmarking their CPU core and not the FLASH implementation of a particular vendor.

Likely just as dramatic is progression in compiler technology. This could be sometimes even more undeterministic. Compilers are able to optimize quite well in the common case but can still produce strange code which also changes on seemingly unrelated code modifications (even when you're not touching a particular routine at all).

Additionally in my experience some architecture specific compiler flags can make certain programs faster, and other programs slower. Sometimes O2 or even Os creates faster code in GCC than O3, which was meant to optimize for speed.

The coremark database always lists the compiler version used and all compilation flags of the program. Benchmarkers are not allowed to make changes to the benchmark code, thus not interfering too much with the optimisations that the compiler can do. Making sure these conditions are met is the fairest comparison; but even then there could be differences here and there.

\$\endgroup\$
  • \$\begingroup\$ Good answer, the "speed per MHz" is highly variable depending on the actual clock frequency, I would think. However, the MCU might counter wait states with data/instruction cache, so the presence/absence of cache should be accounted for in the test. I think serious testing would involve tests at low clock and high clock both. (1MHz versus 100MHz or something like that.) \$\endgroup\$ – Lundin Sep 27 '17 at 9:02
  • \$\begingroup\$ Serious testing would involve the actual application, at target clock speed - not a synthetic benchmark... \$\endgroup\$ – Sean Houlihane Sep 27 '17 at 9:45
  • 1
    \$\begingroup\$ @SeanHoulihane Always. CPU's are designed to score high in benchmarks, because these are the common cases. E.g. the cortex m0+ does not even have a mandatory single-cycle multiplier. That could even mean an 8-bit AVR is faster. If your application does a lot of these operations, then make sure it's available. But translating "your application" to "I need atleast x Coremarks" is (nearly) impossible, so always test. \$\endgroup\$ – Hans Sep 27 '17 at 15:38
3
\$\begingroup\$

The datasheet for the SAM D20 refers to 2.46 too. As you can see if you follow the link on the Arm site to the EEMBC result, the memory configuration, the compiler and the compiler flags make a difference to the results of a benchmark. Since the benchmark is written in C, it's necessary to use a compiler rather than writing in assembler. This is in the nature of benchmarks, they include an aspect of how good a compiler target the core is (and how well the specific C code maps to the hardware).

Cortex-M0+ can be configured with either a fast or a small multiplier. The datasheet for the part here identifies that the single-cycle multiply is implemented. Page 40 of the datasheet identifies r0p1 of the Arm core is implemented.

A significant factor between different low-power MCU parts might be the memory architecture. For example, the flash memory width, any intermediate instruction fetch buffering etc. It's possible, for example to implement a 16 bit wide instruction flash memory (since the instruction set is Thumb), or to have a CPU clock speed higher than the flash speed (and maybe a wide flash interface) - all with different trade-offs.

\$\endgroup\$
  • \$\begingroup\$ I read your question thrice before it clicked as to why you had to use a compiler instead of assembly, gosh :D ! Thanks for the answer it was helpful. \$\endgroup\$ – Alaba Baju Sep 22 '17 at 19:29
  • 2
    \$\begingroup\$ Real code is almost always compiled. There are very few developers who can write faster assembler by hand than a modern compiler generates for a complex problem. \$\endgroup\$ – Sean Houlihane Sep 24 '17 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.