How We See Embedded Processing

Maybe it's just me, and maybe it's just a coincidence, but recently I keep having the same kind of discussion over and over with a number of embedded-control designers. Their request: "Integrate more." My response: "It doesn't always make sense."

Sometimes more integration is not necessarily a good thing. On the contrary, there are several cases in embedded control where partitioning is just what the doctor ordered. Nonetheless, I cannot begin to tell you how uncomfortable it felt. The roles used to be just the reverse. Working for Microchip Technology, I got used to bringing news of yet another peripheral or analog function being integrated in a new series of PIC microcontrollers. After all, a microcontroller is, by definition, an exercise in integration. A microcontroller is nothing more than a microprocessor with all the RAM and ROM (Flash) memory needed. The data and address bus are now internal, and all pins are used to provide analog and digital I/O, or access to onboard peripherals.

It's been almost a decade since we started integrating reset and brown out circuits, and then oscillator circuits of ever higher precision to squeeze all the functionality in ever smaller packages—creating one of the first microcontrollers that would fit in an 8-pin package: the PIC12 series. More recently, we went one step further and launched a series of microcontrollers—the PIC10 series—that fits in 6-pin (2x3 mm) packages. But we have also integrated in larger PIC microcontrollers a growing number of peripherals, from CAN, LIN and USB to Ethernet; from LCD drivers to motor control PWM circuits. We have integrated analog functions, too, including comparators and operational amplifiers, and even shunt regulators, so that the microcontroller could operate off of unregulated, ultra-low-cost power supplies.

So, I understand how it is, in part, the fault of semiconductor manufacturers. We've been pushing integration for so long that it appears like a sort of nirvana for every design to be ultimately squeezed into a single über device. Explaining why this is not always true, I feel like the Intel marketing folks—after 20 years of pushing higher clock frequencies, they are now in the position of having to explain to the public how multiple cores and not just the number of MHz count in determining the performance of a new processor. Not easy. Millions of dollars have been spent in a huge marketing campaign to correct this "perception" problem.

Don't get me wrong, integration is good. It increases the reliability of applications and it reduces the footprint (hence the obvious benefit to the embedded world). But, when it comes to reducing the cost and complexity of a design, we need to be more cautious. Let's analyze a practical example…

When we integrate a small analog circuit (say a comparator) onto the same die of a microcontroller, we are striking a very delicate balance. The space and package cost saved in the final application is, in fact, counterbalanced by an increase in the die cost. The analog circuit, alone, could be implemented in a very simple, low-cost CMOS process. But once it is integrated onto the microcontroller die, it has to be implemented in an advanced Flash CMOS process of higher complexity and, inevitably, cost. If the resulting product is successful, economies of scale intervene in favor of the manufacturer and to the end user's benefit. Otherwise, things can quickly go south. If the resulting product fails to achieve the projected volumes, the cost of the sum can be substantially higher than the cost of its parts. In turn, this produces a higher price that, in a vicious circle, will further reduce the appeal of the product.

There is a second example I would like to offer, which is perhaps closer to your experience in embedded-control design than the economics of silicon manufacturing. Consider a complex application where a lot of computational power is required to manipulate data while controlling hardware in real time. The designer faces a choice between two approaches: an "integrated" approach using a single processor (a 16- or 32-bit architecture) with a very high clock rate and a very large memory to contain the entire application; or a "partitioned" approach using multiple processors (possibly 8-bit, of lower cost and smaller memory).

Once again, this is an example where we, the engineers, have to strike a delicate balance and carefully evaluate the tradeoffs. A faster processor can be relatively inexpensive nowadays, but a lot of its precious MIPS could end up being wasted by the frequent low-level interrupts necessary to maintain the real-time control of the application. Additionally, writing and debugging a large application controlling several simultaneously running tasks can be a complex proposition.

The appeal of the "partitioned" solution, where a few small processors collaborate to control the application, has numerous advantages. Each part of the design can be debugged and tested separately (or in parallel). Also, each part can use not only a smaller processor, but a more specialized one, to best fit the specific task assigned.

You get the picture. For years, we have been (and will probably continue to be) bombarded with announcements of newer and more integrated products. So, we will always have to be alert and exercise our best judgment to decide when we really need more integration, or when we'd be better off partitioning a design.

-Lucio Di Jasio, Microchip Technology