One aspect of this change has been the massive shift to 32-bit CPUs. It's not that all the world's algorithms suddenly started needing 32-bit precision, or that all the world's embedded code has burst the bounds of a 16-bit address space. It's that, ever since about the 0.5-micron process node, the difference in silicon area between an 8-bit CPU core and a 32-bit core has been minimal. So a lot of applications have migrated to 32-bit cores simply to get access to better development tools-a big advantage for coders who learned C on workstations and don't enjoy hand-coding for obscure 8-bit instruction sets.

The other major aspect of the change is that MCUs, like SoC ASICs, have been vacuuming up all the logic and memory components around them. Recent announcements from the major players combine the CPU core not just with memory and general-purpose serial and parallel I/O, but with specialized media-processing blocks, complex bus interfaces and highly flexible memory controllers, sometimes in multiple varieties. With such large transistor counts available, it's easier to overkill on memory and simply to load one of everything onto the die than it is to finesse just the right memory-and-peripheral configuration for each application.

Such MCUs are every bit as much systems-on-chip as their ASIC rivals. The difference is that SoC ASICs are not just application-specific, they are design-specific. The new MCUs may be tuned to a particular family of applications, but they offer a full menu of hardware devices on-chip, many of which may remain unused in any particular design.

It's an irony of the industry's economics that in modest volumes, a standard-product MCU that is only half utilized may be far more cost-effective than either a microprocessor and accompanying FPGA or an SoC ASIC that exactly fits the application. To add a final irony, these MCUs are often used for test-market production of high-volume consumer products that will eventually be implemented in an ASIC SoC.