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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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).

Answer 5

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.

Answer 6

Your wishes came true :) Parallax Propeller 2 runs at 300MHz, has 8 cores, 512kB of shared RAM, 2kB local core RAM + another 2kB shared by pairs of cores, most instructions run in 2 clock cycles so 150MIPS per core or 1.2GIPS peak per chip, 64 very flexible smart pins – you can have 64 1MSPS 15-bit ADCs if you can use them, built using a modern TSMC process (35nm but don’t quote me on that – I couldn’t find the forum posts where that was discussed).

So, as for the question of “why don’t they do it”: but they do! And it’s an amazing part, if I may say so.