I'm wondering if anyone knows roughly what kind of power consumption one can expect from an ARM processor having the ARM8 architecture (ARMv4 instruction set)? (Edited)

Note: I'm not looking for technical specs, but rather a ballpark power consumption in 'typical' circumstances (typical is left open.)

For size of the ARM8/ARMv4 instruction set, I haven't found a source that simply lists them all for the ARM8 (apart from the datasheet -- which would require counting manually!). Surprisingly, I wasn't able to find any marketing material or technical summary that listed the size of the instruction, unlike for Intel, where it was easy to find that 80486 has about 190 instructions.

Edit: Loosely counting the ARMv4 instruction set, I get roughly between 75-100 instructions, depending on whether one includes minor variations or not.

Context: (Edited)

I'm hoping to use the information to make a rough but qualitatively correct comparison between similar chips of similar capability but having different designs, i.e. RISC, CISC, or MISC (minimal instruction set).

For CISC, I have the Intel 80486 at about 50 MIPS, 190 instructions, but using a whopping 1.2 million transistors, and consuming ~3W power.

For RISC, I have the ARM8 at 84 MIPS, 75-100 instructions, using fewer than 50k transistors, and consuming ??W power.

But most interesting in my opinion is MISC, specifically Chuck Moore's MuP21 Forth-in-hardware chip which is listed at about 80 MIPS performance, has only 25 instructions, only 7k transistors, and 50 mW power consumption.

Filling in the ARM chip information will hopefully support factor / order of magnitude comparisons between the three designs.

  • 2
    \$\begingroup\$ Remember that ARM8 is an architecture while the other two you've listed are actual products. There may be many implementations of ARM8 (though Wikipedia only list one). \$\endgroup\$ – Trygve Laugstøl Nov 5 '12 at 11:31
  • 1
    \$\begingroup\$ Cortex M series would seem more reasonable for comparison at this performance level. (M0+ seems to be very small.) Renesas RX is a modern (low-cruft) CISC ISA, but might have a very low-end implementation. One would also want to compare with the same manufacturing technology. Performance and energy efficiency depend on workload and tradeoffs can be made between area, power, and performance. \$\endgroup\$ – Paul A. Clayton Nov 5 '12 at 18:46
  • \$\begingroup\$ Also why are you concerned about the number of instructions? (It can be difficult to count instructions. E.g., is the variant of ADD in ARM that sets the condition code a different instruction?) \$\endgroup\$ – Paul A. Clayton Nov 5 '12 at 18:53
  • \$\begingroup\$ @PaulA.Clayton: Agreed that instruction size is the least important of the attributes. I've included it with the idea that it gives a rough indication of the instruction complexity that the chip designers have to embed in the silicon. Loosely counting the ARMV4 instruction set, I get between 75-100 instructions. That's still almost 3x more than the number in the MuP21 and about half the number in the 486 -- which seems qualitatively about right. \$\endgroup\$ – Assad Ebrahim Nov 5 '12 at 19:09
  • 1
    \$\begingroup\$ @AKE: RX is a CISC but has much less cruft than a 486 so would make a better candidate for a modern CISC (i.e., fair comparison). Unfortunately, the process tech. (and core size) for RX210 does not seem to be public information, but Renesas does publish its Amps/DMIPS rating. ARM publishes W/MHz and DMIPS/MHz for different process tech. implementations of various designs, so if one knew the process tech. of RX210 one could make a comparison. Both CISC and RISC make tradeoffs for more scalable perf. relative to a stack ISA, so a fair comparison is difficult. \$\endgroup\$ – Paul A. Clayton Nov 7 '12 at 13:18

You are not going to conclusively be able to come up with a result, not possible. Benchmarking is always subjective and can often be and is often used to give the desired result (A is better, B is better, C is better etc).

Number of instructions is not relevant, any more than number of registers would be etc. Number of transistors is interesting, but comparing a single soc chip vs a processor that required external chips to provide the same functionality. Or one chip may have large chunks turned off at any one time relative to the other, or may have a large chunk turned off to complete the benchmark, or one may have more transistors, but switch them less frequently than the other which has fewer, possibly leading to different power consumption.

Intel makes and sells chips which happens to have (much of) their stuff inside. Arm does not make chips, they sell IP. Just like how fast does this program in source code form run, varies widely depending on compiler options, processor, etc. That same IP can consume widely different amounts of power depending on the foundry and cell library and process used to implement it. Same architecture, same clock rate, different power consumption. So right off you are comparing apples to oranges in yet another way. I cant think of a real case where an arm core is all that is in the chip, generally you wrap the arm in the chip with a lot of stuff, stuff that with the other processor would be off chip. The proper comparison would be the whole system not just the power of the processor.

This takes you into clocking differences, one processor may be way more efficient than another and can perform the same benchmark at a different clock rate or otherwise using less hardware or power or whatever. Very easy to write a benchmark that runs on a small battery powered microcontroller board that uses less power than an x86 computer even if the x86 is or could be grossly underclocked. Just as easy to write a benchmark that runs lightning fast on an x86 that takes that microcontroller an eternity to finish. Even if you clocked them the same or could.

Just compilers alone make the same computer run the same source code and vastly different speeds. It is simply not possible to compare two systems in this way except for clearly stating exactly the benchmark. This specific code compiled for speed using this compiler which was hand checked to produce this quality of optimized code, ran on this specific system with the system consuming this much power. This other system using this compiler hand checked to provide similar optimization, required this clock rate and this much power to execute in about the same time. Repeat for each of the infinite number of possible benchmark applications users might be interested in.

The mips/mhz comparison relies heavily on the compiler and the application, big variations in mips on the same system with no hardware changes. In no way can you really compare two processors with this method. Published mips to mhz is just marketing fluff, ignore it. Likewise you can put as much faith in the published power consumption as you can in the mips/mhz numbers, it was based on some benchmark, if your application is not the same benchmark, what good is it?

You will need to build a number of systems (lay out each board design specific to the benchmark) and attempt to reduce the number of variables, or ideally take the approach of making the bare minimum system, max optimization, capable of running the benchmark at exactly X amount of time. Repeat for the other system, then compare the power consumption of the whole system for the duration of the execution of that benchmark. Repeat for the millions of different benchmarks, in order to get a fair and general comparison it may not be possible to reduce the results in any conclusive way.

For an architecture difference you ideally want to have the processors built at the same foundry using the same cell library and same process, etc. If you are willing and able to license competing cores, populate the chips to the same level, use similar bus rates and as much similar external hardware (the system buses are no doubt different, making a common bus from them might give one an unfair advantage). Same amount of caches with same advantages, etc. You might have a better chance at a comparison that actually looks real. This would be the only way to come up with something plausible, same benchmark run on different architectures made at the same foundry, same cell library, same process, same cache size, same dram, etc. Can still manipulate the benchmarks to make either one the fastest or lowest power consumer.

What would be more interesting is an empirical comparison. Take or create benchmarks one at a time, look at the various ways to generate code from the compiler. Examine the buses that you can examine, get a feel for fetch sizes. If possible with the fixed vs variable word length instructions can you tell from the buses where the variable length decisions are made, first byte tells you might need to examine the second byte, second byte may make you realize you need 4 more bytes for the immediate, now you can execute. How much has to be jammed in near the decoder to make this efficient? How much do you have to discard and fetch if there is a branch, how fast does this happen? You have to look at quantity of code to perform similar tasks, due to different number of registers (real or virtual)(x86 is microcoded or many are, arm is not microcoded) how often does the code have to swap out registers on the stack (very easy to write benchmarks that punish one architecture relative to another for this). x86 can store more program in the same size cache than an arm, but the arm is more deterministic in decoding that code. x86 incurs more alignment punishments than arm, as it lends itself to not be aligned where arm is either encouraged or forced. Can you construct benchmarks that show an advantage for each instruction set, should be very easy to make a loop that fits x86 instructions within a cache of some size, but does not fit arm instructions in the cache of the same size. might be easy to have a benchmark that branches heavily that might show arms advantages or at least shoes one branch predictor vs another. clocks and power are still out of the picture, but performance at least at some layer you can see and the project that into the caches and dram responses to finish the understanding.

Anyway that was a tangent, you cannot compare two processors in this way and have those in the know accept the results as anything meaningful. The masses may be fooled, but not those who know what is going on. Empirically demonstrating advantages and disadvantages, that might be more doable and interesting to all. comparing opencores in the same fpga, that might be interesting as well, but one commercial processor chip on a commercial board, compared to IP that can be implemented many many different ways on many different boards, just wont be plausible.

  • \$\begingroup\$ Hi there - thanks for such a detailed response. So, I agree with many of your points. And your recommendations seem very reasonable if one were interested in a definitive study, perhaps a dissertation, or comprehensive technical report. However, surely there must be a way to use specifications to understand relative performance differences between different architectures / designs? Otherwise what is the use of specs at all? \$\endgroup\$ – Assad Ebrahim Jan 8 '13 at 8:18
  • \$\begingroup\$ To some extent the specs are accurate, to another extent the specs are advertising trying to sell you a product with flashing lights and dancing girls. The specs for chips that use arm cores are readily available, problem is you cannot compare them apples to apples with say a 486 chip. you need to look at the system. the architecture though, is a design and source code it is not an implementation so it does not and cannot have a power number until implemented. Like compiling a program each implementation of the same source can vary quite a bit. \$\endgroup\$ – old_timer Jan 8 '13 at 15:02
  • \$\begingroup\$ Fair enough. Do you have any views on the MISC chips running a stack model -- hence simpler than either of the other two. That's the main driver for the comparison since the MISC chips are, per spec, able to deliver comparable performance for substantially less power draw using much simpler silicon. \$\endgroup\$ – Assad Ebrahim Jan 8 '13 at 19:11
  • \$\begingroup\$ I am not at all familiar with that chip/architecture. usually simpler silicon, esp stack based means a lot more memory cycles which is generally slower. I would really have to see it in action, is there verilog source that can be used in a simulation? (verilator or icarus?) \$\endgroup\$ – old_timer Jan 9 '13 at 1:13
  • \$\begingroup\$ I see what you mean by misc. From wikipedia: The disadvantage is that instructions tend to have more sequential dependencies, reducing instruction-level parallelism. \$\endgroup\$ – old_timer Jan 9 '13 at 1:20

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.