MCore: Does Motorola Need Another Processor Family?

by Jim Turley

Motorola has added yet another architecture to its potent processor arsenal. But is it really necessary? If so, how does it fit into the company’s portfolio? Here’s one embedded guru’s take.

After years of secret development, Motorola released MCore, its latest embedded processor family. But why would Motorola, a company that already has nearly a dozen different CPU families, need yet another processor line? It’s tempting to label this latest development a sign of corporate schizophrenia, or a lack of market focus. But MCore serves a real purpose in Motorola’s grand product strategy, and fills a hole that even the processor powerhouse couldn’t fill any other way. Let’s review. Motorola now has no fewer than four different families of 32-bit microprocessors: PowerPC, 68000, ColdFire, and now MCore. These are in addition to the company’s popular 68HC05, 68HC08, 68HC11, 68HC12, and 68HC16 families. Does Motorola really need yet another line of chips for embedded systems?

Yes, it does. Motorola knows embedded systems well, and few companies are better equipped to understand that one size doesn’t fit all. Even with all these CPUs at its disposal, Motorola couldn’t compete in some of the biggest markets of all, and it was letting business get away. In particular, Motorola was falling behind in competition for small, portable wireless systems (which is ironic, since Motorola makes cell phones itself). It also didn’t have a good way to upgrade customers from its many 16-bit CPUs and gently introduce them to the 32-bit world. MCore fills both of those needs. The venerable 68000 survives for the sentimental. More than that, it thrives. The 68K is still the best-selling 32-bit architecture in the world. Seventy-nine million 68K chips went out the door in 1997, compared to about 75 million Pentium-based PCs. Motorola isn’t about to give up on that cash cow.

ColdFire is, of course, a spin-off from the 68K family: a 68000 dragged kicking and screaming into the ’90s. ColdFire maintains many of the traditional charms of the 68K—such as its programming model and part of its instruction set—but jettisoned many of the features that accreted onto the good ship 68000 over its years in the workstation and computer business. PowerPC is for the performance-minded developer. PowerPC will always (well, at least for the foreseeable future) be Motorola’s premier embedded CPU family, always pushing the performance limit. PowerPC also supports the major operating systems, like Windows CE, VxWorks, pSOS, and others. MCore is something apart from all of these. From the cradle, MCore was tweaked and teased into a compact, inexpensive, low-maintenance microprocessor. Specifically, MCore boasts some of the best code density (in terms of its small memory footprint) of any 32-bit processor. MCore is also small and simple to manufacture, using just a tiny sliver of silicon. MCore is not particularly fast, but it does provide a nice bridge between 16-bit CPUs and the big iron of 68K, ColdFire, and PowerPC.

The Chip Itself
MCore has many microcontroller-like features that users of 16-bit chips may recall fondly. It maintains two identical register sets, as Figure 1 shows. All sixteen 32-bit registers from one set are visible at any time. The only restrictions are that r0 (the stack pointer) and r15 (the link register) are used by a few instructions and that you can’t see both sets of registers at once. Programs can switch back and forth between the primary and alternate register sets at any time. Typically, you’d use one set for program code and the other (it doesn’t matter which) for interrupts and exceptions. Like a RISC chip, only loads and stores can access memory; all other instructions work on register contents only.

But MCore is no RISC: it has vectored interrupts, a no-no in the RISC world. Each of 128 different interrupt sources can have its own interrupt vector. Each vector is a 32-bit pointer into the interrupt handler. The programmer can use the least-significant bit of the vector to choose whether the interrupt handler uses the primary or alternate register set. MCore also handles hardware vectoring like a 68000 or like the 6800 before it. For simplicity, hardware interrupts can either take the default vector, or the hardware can supply its own vector. In the latter case, the vector is driven onto the data bus at the same time the interrupt is signaled. This is easier and faster than the 68000 way, where a separate interrupt-acknowledge cycle fetches the vector. The MCore way is simpler, faster, and eliminates the unbounded time spent fetching a vector from an unknown source.

MCore’s claim to fame is its code density. Among Motorola’s 32-bit chip families, MCore uses less memory than even the 68000. It competes with ARM’s Thumb and the MIPS16 code-compression techniques but without switching back and forth between instruction sets. Each MCore instruction is fixed at just 16 bits: no more, no less. There aren’t many 32-bit CPUs on the market that do this, with Hitachi’s SuperH being the notable exception. The 16-bit instruction word means that MCore chips can fetch code across a 16-bit bus. Most other 32-bit processors would immediately cut their performance in half as they struggled just to feed themselves. Fetching code across the bus is not Motorola’s intention, however. Rather, on-chip RAM and ROM were among the keys to MCore’s development. Companies like Motorola become very interested in code density when they start supplying microcontrollers with on-chip memory. Code density is a nice selling feature when the customer is supplying the memory, but it takes on a whole new significance when the chip maker is devoting its own precious silicon to memory.

Silicon real estate is money, and MCore chips are (so far) mostly memory. The die photograph in Figure 2 shows Motorola’s very first commercial MCore chip, called the MMC2001 (sure to be a problem for dyslexic Romans). The photograph illustrates how the chip is about three-quarters memory and only about 5% CPU. With those proportions, it’s no wonder that Motorola emphasizes code density so much. For all of its corner-cutting, MCore still has some nice features. The chip can do both signed and unsigned adds and subtracts, 32-bit multiplication, and even has a divide instruction. Division is iterative, so it takes anywhere from three to 37 clock cycles to execute, but it’s better than calculating quotients “manually” using subtract and shift instructions. MCore also has instructions for ABS (absolute value), FF1 (find first one), and BRV (bit-reverse) that are useful in cryptography. Conditional move, clear, shift, increment, and decrement instructions can help avoid many short branches.

Amazingly, almost 15% of MCore’s cramped opcode map is still unused, leaving ample space for future enhancements. Motorola is already talking about adding pseudo-DSP instructions like multiply-accumulate, which could make MCore useful for data communication tasks or for simple audio processing.

With an Eye to the Future
In this industry, few undertakings are more expensive than designing and supporting a completely new processor family and a new instruction-set architecture. AMD cancelled its 29000 line even though it was selling millions of chips per year, simply because the support costs were too high. Compilers, debuggers, and all the third-party support infrastructure can sap the resources of even the biggest companies. To be sure, Motorola did not undertake this task lightly. The company realizes its future is in embedded control, not desktop computers. And since there’s no such thing as a typical embedded application, there’s no hope that one processor family would be right for them all. Makers of cellular telephones, video games, industrial controllers, robotics, and automotive systems all have different needs. And each market segment is big enough in itself to warrant its own line of microprocessors.

The fastest-growing segments of the embedded world are not the traditional embedded systems of gears and grease. Consumer electronics are driving sales volumes and technical innovations. To be a part of that boom, Motorola needed a new family of parts designed from the start for good code density, low power consumption, and small chip size. MCore fits that bill and also provides a comfortable step up from the company’s many 16-bit families. In another ten years, embedded designers may wonder what took Motorola so long.

Jim Turley is the senior editor of Microprocessor Report. He is an editor, speaker, and industry analyst specializing in microprocessors for handheld, portable, and embedded applications. Turley has been quoted in the Wall Street Journal, Forbes, San Francisco Chronicle, and USA Today. He is the author of several books, including the best-selling PCs Made Easy, published by Osborne/McGraw-Hill.

Return to Embedded.com

Send comments to: Webmaster
Copyright © 1998 Miller Freeman, Inc.,
a United News Media company.