MCUs will play an increasingly critical role in cars and IoT devices, but they’re also becoming much more difficult to design.
Microcontrollers are becoming more complex, more powerful, and significantly more useful, but those improvements come with strings attached.
While it’s relatively straightforward to develop multi-core microcontroller (MCU) hardware with advanced power management features, it’s much more difficult to write software for these chips because memory is limited. CPUs can use on-chip memory such as SRAM, or off-chip memory such as DRAM. But with an MCU, everything is on-chip. So while CPUs can run heavy-duty operating systems such as Linux or Windows, MCUs require much lighter real-time operating systems, many of which are customized for one or more specific functions.
“If you look at the vision market, you can support MCU-style or CPU-style vision applications and even have overlapping applications,” said Chris Rowen, a Cadence fellow and CTO of the IP Group. “With an MCU you’ll have lower frame resolution on-chip. And there is a diversity of interfaces that are complex, whether it’s a CPU or an MCU. But with a CPU you can afford to be a little sloppy, like writing out the whole buffer. You may not have room to do that on an MCU. The handoff is trickier, as well, and the opportunity for bugs to be introduced is higher.”
It becomes even more difficult if MCUs are used to offload CPUs, either as an accelerator, a co-processor, or as a less-powerful, more energy-efficient backup processor.
“With MCU programming, the challenge is keeping up with processes,” said Rowen. “I don’t care if my garage door opener goes away for hundreds of microseconds and then comes back, but if you’re trying to keep up with a high-speed data stream you need parallelism. So if you’re looking at an MCU as another sub-engine, you need the processor to be able to do data computing, and that requires programming style that is much less forgiving. When you take an MCU and move it into a high-data-rate environment, it gets much more difficult.”
Adding to the confusion, MCUs increasingly are being used in non-standard ways, in more places, and frequently they are embedded into more complex SoCs. So while functionality may be limited to a specific task, such as waking up a CPU, getting multiple MCUs to synchronize across a device is much more difficult from a design, verification and coherency perspective.
“The trend is accelerating where we’re seeing a combination of [ARM] Cortex A (CPU) and M (MCU) cores on the same SoC,” said Andrew Caples, senior product line manager for embedded products at Mentor Graphics. “If you look at ADAS (advanced driver assistance systems), for example, which are the crème de la crème of embedded applications, you can do this now with lots of processing units—MCUs, MPUs, DSPs. That should equate to longer mean time to failure, a lower bill of materials cost and less heat dissipation. But it also adds to the complexity. So you have multiple RTOSes on the MCU, MPU and DSP, and you are now developing and debugging on a single SoC package. That means you’re developing solutions to work across heterogeneous platforms, and it puts a lot of pressure on semiconductor vendors to develop libraries and solutions that make utilization of all of these devices more viable.”
Caples said anytime there are multiple cores and operating systems, there are a number of synchronization issues because one core has to wait on another core.
“We’re constantly looking at tooling in this space,” he said. “For the hardware guys, has worked well for them over the years. As hardware performance increases, costs go down. It’s the opposite for software development. As more complexity is added, costs increase. And there is not anything that will help change that.”
Welcome to the MCU age
Despite the challenges, the role of MCUs in complex systems is expected to increase as more things are designed to be connected and, increasingly, to communicate with other things. MCUs are highly energy efficient, and they are inexpensive compared with CPUs. The 8-bit MCU will continue to play an important role in performing basic tasks, while the 32-bit and even 64-bit multi-core MCUs can handle more complexity. And all of them could end up in the same SoC alongside a CPU or a GPU that remains dark most of the time.
“There is more and more complexity in MCUs,” said Bill Neifert, director of models technology at ARM. “We saw that beginning with the introduction of 32-bit microcontrollers. Then people began asking what else could you do with them.”
The answer, as it turns out, is quite a bit more than just meeting safety and security requirements in automotive applications. Microcontrollers are turning up in everything from industrial equipment to smart slippers that can detect when a person has fallen. In those cases, a microcontroller often fits the bill because it offers a cost-effective and energy-efficient embedded processor that can be purpose-built for a specific application.
“Everyone wants the most effective solution, and a custom microcontroller can deliver cost and power advantages over a general purpose product,” Neifert said. “IoT devices in particular are often extremely battery-sensitive, so customers look for special-purpose products that can be turned around quickly—especially for consumer-oriented sectors. Custom MCUs do require modeling but it’s far less complex than modeling CPUs or GPUs.”
Complexity is relative. “We’re going to have 64-bit microcontrollers that can really do some intelligent things,” said Jim Hogan, managing partner of Vista Ventures. “But the code stack is going to be pretty limited.”
Alongside this shift, computing itself is evolving—particularly for IoT applications. “It’s not traditional compute,” said Zach Shelby, vice president of IoT marketing at ARM. “We’re seeing 32-bit and 64-bit microcontrollers making their way into MEMS pretty quickly, for example. But the problem is how we get the right types of software applications that are high-volume enough that they do the same things over and over. FPGA doesn’t quite work for low-power applications. If you do specialized mixed-signal vision detection algorithms on silicon, you have to use a microcontroller, but it’s the same application over and over again.”
The challenge is getting MCUs to play nicely with each other and other processors, given the limited amount of on-chip memory. One of the big issues being dealt with everywhere in system design is more data, particularly streaming image processing and pattern/image recognition. There are a couple high-level approaches to solving that. One is to have faster processors and more memory. The second is to have more processors that can do certain jobs more efficiently. Even if the individual processing units are slower, collectively they can get the job done in a reasonable amount of time, and they can be dialed down as needed.
“You need that flexibility because you have many heterogeneous applications that you want to process and you don’t want to compromise on the performance based on a very homogenous model, which is what the CPU and GPU have been designed for,” said Sundari Mitra, CEO and co-founder of NetSpeed Systems. “The advantage of a microcontroller is that they have sort of a programmable microcode engine, so you can sort of architect them in environments where they are a little bit more flexible than a hard processor kind of IP. A microcontroller allows you some flexibility—not too much, but some. It gives people the opportunity to be flexible in their architecture. A CPU is really good for floating-point algorithms. A GPU is really good for vision-based processing. What MCUs are good at is somewhere in between. These can be IoT edge devices like your wearables. These can be MCUs in your automotive engines. What is different between them is you need an architecture that is adaptable and flexible enough. If people understand their workflows, and if they optimized for that, the MCU allows you to bring in some diversity and have heterogeneity in your compute engines.”
Defining MCUs
MCUs, in general, are slimmed down processing units that run at lower clock speeds than CPUs and GPUs. The memory hierarchy is the most obvious difference, particularly with 8-bit and 16-bit versions, which are popular because of low cost and much lower power. But the line is blurring a bit with advanced 32-bit MCUs and low-end CPUs. It becomes even fuzzier with 64-bit multicore MCUs.
“At a big picture level, CPUs are generally optimized either for a single thread or multithread performance depending on the application workloads,” said Mitra. “If you take it into something that is more real time — this is what IoT is — it’s about making more real-time decisions. Their workloads are not optimized for those things. Maybe their workloads are optimized more for sensing what is happening in the environment and making a decision based on that. And you’re not going to be sensing the same thing again and again. There is a lot of machine learning that is involved in ensuring that you are learning and adapting. You learn more, you adapt more towards that. That’s where the MCUs are coming in. So what is different about working with MCU’s? CPU and GPU are very well understood. Whereas MCU’s are not. You have to work with slightly more limited information. And the design parameters are changing, so your design needs to be workable for that.”
That also makes it hard to clearly define MCU markets, and it makes it difficult to come up with apples-to-apples projections about how this market is faring. In a report published earlier this month, Brisk Insights predicted the MCU market will grow at a 15.8% compound annual growth rate through 2022, propelled in large part by the IoT, with 32-bit microcontrollers showing the fastest growth. Databeans put the growth at 6%, driven largely by industrial demand.
From a vendor perspective, Gartner identifies the top players in this space as Renesas, NXP, STMicroelectronics, Microchip, Texas Instruments and Infineon, in that order.
But as MCUs show up in new places with new use cases, the market becomes much more fragmented and difficult to track.
“When we see more and more complicated chips, they almost always contain MCUs,” said Kurt Shuler, vice president of marketing at Arteris. “So in cars there are lots of them sprinkled around individually, but even in bigger chips there are MCUs running in the background. They’re also prevalent in wireless digital basebands.”
Customized code to run on these devices can make them highly power-efficient, and there is work underway to push that even further through slower wake-up time from sleep mode for certain functions. But the challenge may be less about capabilities of the hardware than how to leverage those capabilities from a system perspective.
Conclusion
MCUs are a work in progress. Even the definition is changing. But the direction is clear. These will be workhorses in edge node devices for years to come, and across many devices that ultimately will be connected or are capable of being connected to the Internet and potentially even to other processors.
But how much of the MCU’s potential is truly harnessed remains a subject for future discussion. Mentor’s Caples said it may take man-years in software development to utilize some of the capabilities being built into these devices. “No one has the time to do that.” At least not yet.
Related Stories
How To Choose A Processor
There is no clear formula for what to use where, but there are plenty of opinions about who should make the decision.
Rethinking Process Architectures
General-purpose metrics no longer apply as semiconductor industry makes a fundamental shift toward application-specific solutions.
Rightsizing Challenges Grow
More factors enter into decisions about how to optimize designs for specific applications.
I think this sums up the problem and the rest of the article is just buzz words and cryptic quotes..
““At a big picture level, CPUs are generally optimized either for a single thread or multithread performance depending on the application workloads,” said Mitra. “If you take it into something that is more real time — this is what IoT is — it’s about making more real-time decisions”
And all the pipe-lining, out-of-order execution, and JITting just gets in the way of making real-time decisions.
1) if you go off and build a custom MCU, you just saddled your self with writing a compiler.
2) Why are there 64 bit MCUs when 8 and 16 bit MCUs are to be known to be adequate?
3) How does one run an existing OS on a custom MCU?
4) Is bare metal code running on a custom MCU an OS as the article says there are many OS’s running on the many MCUs n the chip?
5) A chip running bare metal C code in minimum memory footprint with no CPU, MMU makes sense because there is no compiler or RTOS. Further it can be scaled to whatever width is appropriate. C source code is just a syntax to describe the logic of the function. The compiler just re-formats the function into an ISA(or worse yet, an intermediate language used by a JIT compiler)
6) A single core limited to a single ALU, multi-core has multiple ALUs, but writing code to use them efficiently is TBD.