# Why are relatively simpler devices such as microcontrollers so much slower than CPUs?

Given the same number of pipeline stages and the same manufacturing node (say, 65 nm) and the same voltage, simple devices should run faster than more complicated ones. Also, merging multiple pipeline stages into one should not slow down by a factor grater than the number of stages.

Now take a five-year-old CPU, running 14 pipeline stages at 2.8 GHz. Suppose one merges the stages; that would slow down to below 200 MHz. Now increase voltage and reduce number of bits per word; that would actually speed things up.

That's why I don't understand why many currently manufactured microcontrollers, such as AVL, run at abysmal speed (such as 20 MHz at 5 V), even though far more complicated CPUs manufactured years ago were capable of running 150x faster, or 10x faster if you roll all pipeline stages into one, at 1.2 V-ish. According to the most coarse back-of-the-envelope calculations, microcontrollers—even if manufactured using borderline obsolete technology—should run at least 10x faster at one quarter of the voltage they are supplied with.

Thus the question: What are the reasons for slow microcontroller clock rates?

• A good chunk of microcontrollers are manufactured with bordline obsolete technology because the fab is paid for. – Matt Young Apr 11 '16 at 18:31
• Power. Factor in the power consumption of both CPUs and they'll be quite close to the same performance/watt, or the micro will win. – Brian Drummond Apr 11 '16 at 18:51
• The idea that simpler == faster is simply wrong. A lot of the complexity of a modern cisc CPU goes into features to make it faster, like multi level caches, pipelines and branch prediction – PlasmaHH Apr 11 '16 at 19:13
• that old cpu doesnt run from a small battery for months/years. used cutting edge (read: expensive) technology for its day. didnt have to wait on slow/cheap flash for every instruction. there is rarely a need for an mcu to run fast, they can take some new verilog for the sake of the developers and implement it on whatever foundry. I like the bicycle vs formula 1 car comment the best, I think that sums it up. – old_timer Apr 11 '16 at 19:56
• 20 MHz is not slow at all. We are just pampered by GHz speeds for PCs, where most of the resources are used for rendering fancy graphics. You can fly to the Moon with a Kilohertz processor... – vsz Apr 12 '16 at 4:27

There are other factors that contribute to the speed.

• Memory: Actual performance is often limited by memory latency. Intel CPUs have large caches to make up for this. Microcontrollers usually don't. Flash memory is much slower than DRAM.

• Power consumption: This is often a big deal in embedded applications. Actual 200 MHz Intel CPUs consumed more than 10 watts (often much more), and needed a big heat-sink and a fan. That takes space and money, and it's not even counting the external logic and memory that went with it. A 20 MHz AVR takes about 0.2 watts, which includes everything you need. This is also related to the process -- faster transistors tend to be leakier.

• Operating conditions: As Dmitry points out in the comments, many microcontrollers can operate over a wide voltage and temperature range. That ATMega I mentioned above works from -40C to 85C, and can be stored at anything from -65C to 150C. (Other MCUs work up to 125C or even 155C.) The VCC voltage can be anything from 2.7V to 5.5V (5V +/- 10% for peak performance). This Core i7 datasheet is hard to read since they trim the allowed VCC during manufacturing, but the voltage and temperature tolerances are certainly narrower -- ~3% voltage tolerance and 105C max junction temperature. (5C minimum, but when you're pulling >100 amps, minimum temperatures aren't really a problem.)

• Gate count: Simpler isn't always faster. If it were, Intel wouldn't need any CPU architects! It's not just pipelining; you also need things like a high-performance FPU. That jacks up the price. A lot of low-end MCUs have integer-only CPUs for that reason.

• Die area budget: Microcontrollers have to fit a lot of functionality into one die, which often includes all of the memory used for the application. (SRAM and reliable NOR flash are quite large.) PC CPUs talk to off-chip memory and peripherals.

• Process: Those 5V AVRs are made on an ancient low-cost process. Remember, they were designed from the ground up to be cheap. Intel sells consumer products at high margins using the best technology money can buy. Intel's also selling pure CMOS. MCU processes need to produce on-chip flash memory, which is more difficult.

Many of the above factors are related.

You can buy 200 MHz microcontrollers today (here's an example). Of course, they cost ten times as much as those 20 MHz ATMegas...

The short version is that speed is more complicated than simplicity, and cheap products are optimized for cheapness, not speed.

• Don't forget the robustness: a typical CPU will fail if the supply voltage changes by more than 5% or so, while an ATMega runs from anything in 1.8-5.5V range at 4MHz. – Dmitry Grigoryev Apr 12 '16 at 8:44
• @DmitryGrigoryev Good point! I've updated my answer. – Adam Haun Apr 12 '16 at 21:47

A major underlying technical reason for the slow speeds is that cheap/small MCUs only use on-chip flash memory for program storage (i.e. they don't execute from RAM).

Small MCUs generally don't cache program memory, so they always need to read an instruction from flash before they execute it, every cycle. This gives deterministic performance and #cycles/operation, is just cheaper/simpler, and avoids PC-like issues where code and data are mixed creating a new set of threats from buffer overflows, etc.

The latency of reading from flash memory (on the order of 50-100ns) is much slower than reading from SRAM or DRAM (on the order of 10ns or below), and that latency must be incurred every cycle, limiting the clock speed of the part.

• Also power (and therefore heat) increase more than linearly with frequency. – Kimberly W Apr 11 '16 at 20:34
• I don't think reading from flash is anywhere near 100 ns, is it? IIRC it's two orders of magnitude bigger. However, if your flash controller contains a small DRAM cache, and the code is not too branchy, the cache hit rate can be very high (90%+) so your average latency can be a lot lower. – MSalters Apr 12 '16 at 13:12
• This AT91SAM7S datasheet I have open says for its internal flash "Fast access time, 30 MHz single-cycle access in Worst Case conditions" for its internal flash. That's 33ns. And it has one dword of prefetch buffer. Off-die Flash may indeed have higher latency. – pjc50 Apr 13 '16 at 14:44
• @Jamil I don't remember the the exact formula, but I believe it was square of frequency. – Jan Dorniak Apr 13 '16 at 15:13

Why do people ride a bicycle or a small motorbike, when you have a Formula 1 car? Surely it must be better to drive say 300 km/h and get everywhere instantly?

To put it simply, there's no need to be faster than they are. I mean, sure there is a bit and faster microcontrollers do enable some things, but what are you going to do in say a vending machine that is in continuous use for maybe 1 hour a day? What are you going to do in a say remote controller for a TV?

On the other hand, they have other important capabilities, like low power consumption, being MUCH simpler to program and so on. Basically, they're not processors and do different things.

• @Michael Where do you get the idea simple = fast? – Matt Young Apr 11 '16 at 18:38
• @Michael A bicycle is much simpler than a car, but it's still slower. In any case, Matt is right. Something simple is not automatically fast. That is to say, something fast is going to be complicated, just due to considerations needed for higher frequencies. – AndrejaKo Apr 11 '16 at 18:41
• High performance CISC processors tend to issue way more instructions that simple embedded processors. They are doing a lot more work in parallel, so they are both more complex and faster. – Kimberly W Apr 11 '16 at 20:33
• @Michael $1 could be luxuriously expensive for some applications, I've read that the micro-controllers in micro SD cards cost around 19 cents – Xen2050 Apr 12 '16 at 17:40 • @Michael "that's the whole idea behind RISC architectures: simple tasks can be handled faster than complicated ones" No! Modern RISC architectures are extremely complex because they have to introduce more instructions (like SIMD) and support more features like superscalar, hyperthreading, out-of-order execution... Their complexity may easily exceed CISC architectures. MIPS nowadays have hundreds or thousands of instructions. "CISC v RISC is largely a historical debate" – phuclv Apr 13 '16 at 7:25 There are plenty of ARM controllers that run at hundreds of MHz or more. Who needs a 500 MHz PIC and is willing to pay enough per part to justify million dollar masks for a close to state-of-the-art process? The popular ATmega328 is reportedly made with 350 nm technology, which is quite a bit behind the latest production Intel CPUs (14 nm for Skylake). Even the cheapie 8-bit controllers have slowly been edging up in speed, and you can get 32 and 64 MHz PIC controllers (for example, PIC18F14K22) that still operate at 5 V (the latter is a consideration in total system cost). One consideration is that these controllers have an architecture that is optimized for small memory spaces and slow clock speeds. Once you start getting into high clock speeds you have to rejig things with prescalers, etc. There was an attempt made way back (late 1990s) to produce very fast PIC-like controllers, with the idea that firmware could substitute for peripherals if the microcontroller was fast enough. For example, you could bit-bang a UART. I don't think they were all that commercially successful- Scenix->Ubicom->Qualcomm (game over). • 350 nm? That would explain it. Didn't know that anybody would manufacture anything using 20 year old technology. – Michael Apr 11 '16 at 18:57 • Some of us are still designing in (not just using) 4000 series CMOS which is something like 3000nm. – Spehro Pefhany Apr 11 '16 at 19:02 • Older processes are also potentially useful for folks dealing with radiation environments, or high-reliability systems that demand traceability. – Krunal Desai Apr 11 '16 at 19:30 • Game not over -- the Parallax Propeller is a continuation of that concept. – Dave Tweed Apr 11 '16 at 19:31 • @Michael: It's not just the age of the technology. The size matters as well. Larger process size have lower defect rates which means lower rejects and thus higher yield - that leads to lower cost per chip. If you're willing to pay$100 for a CPU (like desktops) then the higher cost due to lower yield is justified. If you're only willing to pay 50 cents then it's not justified. – slebetman Apr 12 '16 at 5:45

Imagine one wants to produce automobiles. One approach would be to use a bunch of pieces of equipment in the factory sequentially, building one car at a time. This approach can be done with a modest amount of moderately-complicated equipment, such many pieces of equipment may be used to perform more than one step. On the other hand, much of the equipment in the factory would still be sitting idle much of the time.

Another approach is to set up an assembly line, so that as soon as the equipment that handled the first step of production has finished that operation on the first car, it can then proceed to start the corresponding operation on the next car. Trying to reuse one piece of equipment at multiple stages in the manufacturing process would be complicated, so in most cases it would be better to use more pieces of equipment that are each optimized to perform one very specific task (e.g. if it's necessary to drill 50 holes of 10 different sizes, then a minimal-equipment setup would include one drill with 10 bits and a quick-change mechanism, but an assembly line could have 50 drills each with one permanently-installed bit and no need for a quick-change).

For things like DSPs or GPUs, it's possible to achieve very high speeds relatively cheaply because the nature of work to be performed is very consistent. Unfortunately, many CPUs need to be able to handle arbitrary mistures of instructions of differing complexity. Doing that efficiently is possible, but it requires very complex scheduling logic. In many modern CPUs, the logic necessary to "do work" isn't overly complicated or expensive, but the logic necessary to coordinate everything else, is.

• Sorry if I missed it, but what relevance does this have to CPUs vs 'slower' microcontrollers? It only seems to focus on CPUs vs (typically even faster) specialised processors. – underscore_d Apr 13 '16 at 21:10
• @underscore_d: The first paragraph covers the simpler microcontrollers--they're like the small shop that builds one car at a time. The second paragraph notes that there are some cheap controllers that can perform lots of operations very quickly, but are limited in the kinds of operations they can do. What's hard is being able to perform an arbitrary mix of operations while overlapping them to a significant (but highly variable) degree. If one has a subsystem which on every cycle can accept two numbers and will output the product of two numbers that were submitted four cycles ago, and... – supercat Apr 13 '16 at 21:41
• ...another that will on each cycle accept two numbers and output the sum of the that were submitted two cycles ago, trying to figure out when values need to be submitted, when results will be available, when things should be loaded from and saved to registers, etc. can get very complicated, especially if one wants to avoid padding out all the pipelines to match the longest one. – supercat Apr 13 '16 at 21:44
• Thanks; that clears it up. Yeah, it makes sense that fast general-purpose CPUs incur most of their costs, both financial and energy, on 'scaffolding' - pipelining, cache, scheduling, RAM control, etc. Things that are not only prohibitively costly but also often not required for micros. Equally, it never ceases to amaze me what can be done with a relatively tiny clock frequency in a processor specifically tailored for one application. Fascinating stuff on both sides! – underscore_d Apr 13 '16 at 21:58
• @underscore_d: The MIPS architecture was designed on the premise that compilers would be responsible for some of the scheduling issues, thus allowing hardware to be simplified. The concept never really caught on, I think, because newer processors often require more pipeline stages than older ones, but code written for a processor with shorter pipelines won't work on a processor with longer ones in the absence of hardware interlocks. – supercat Apr 13 '16 at 22:04