Embedded Design Embrace Multicore, but Challenges Remain

In the past few years, multicore systems have garnered a lot of attention as semiconductor companies worked to overcome the issues of higher power consumption and greater thermal output. These efforts were reflected in each new generation of faster processors. Of course, systems that use large amounts of processing power in the form of networks of processors, which are running a limited number of applications, have existed for a long time. In a multicore system, however, all of the processors reside on a single piece of silicon.

For three decades, the Semiconductor Industry roadmap has been driven by Moore's Law. This law has facilitated the ongoing revolution in the electronics equipment industry touching upon all vertical segments. The era in which PCs were the market driver was followed by the networking and telecommunications markets. Now, it is the consumer-electronics segment's turn to be the new growth engine. In the quest for faster processors and better performance, however, power consumption and thermal issues have been significant barriers. Power consumption is an especially thorny issue in the context of consumer-electronics devices. Similarly, heat generation and dissipation are significant. While using a mobile phone as an ear warmer in cold climates may have great appeal for certain users, it isn't going to be a universally requested function.

Semiconductor companies have therefore been on a quest for a way to substantially improve processing performance and processor speed while addressing power and thermal issues. Intel® dual- and quad-core products and the recently announced 80-core project are all examples of the company's efforts to provide more raw processing power for the next generation of products. Faster processors are generating more heat and consuming more power. As a result, the idea is to lower the speed of each processor while providing greater overall processing resources. Doing so should decrease overall application execution time while constraining power usage.

Homogeneous and Heterogeneous Multicore Systems

One thing to keep in mind is that multicore systems can be homogeneous or heterogeneous. A heterogeneous multicore processor will have some combination of control processors and digital signal processors (DSPs) among other hardware elements. In a homogeneous system, the multiple cores are of the same kind and each core may run the same application. In the networking domain, for example, it's not uncommon to have a networking chip with 128 cores on it—where the majority if not all of the cores are homogenous. There may be one application-specific processor to handle some control events.

In this environment, the data set that has to be processed and synthesized is well understood and the processes are repetitive. In addition, a large number of multicore systems in use today follow a symmetric-multiprocessing (SMP) architecture. The problem set is magnified when dealing with heterogeneous, asynchronous systems as typified by most high-end consumer devices. Most embedded systems tend to be heterogeneous systems.

As semiconductor and systems companies have discovered over many product generations, leading-edge hardware isn't always enough to make the sale. The platform has to be supported by software to enable the technology and the platform to proliferate in the market. The embedded-software-tools marketplace—and the real-time-operating-system (RTOS) market in particular—have their origins in the non-recurring-engineering (NRE) fees. Semiconductor manufacturers pay these fees to vendors to support the new hardware platforms. With the new multicore platforms, however, the traditional approach is starting to fail.

Software programmers and application developers who understand how to program embarrassingly parallel multicore systems do exist. Yet they're a small minority of the programmer community. Mostly, they work in application-specific domains. Mainstream software-programming models are primarily sequential—as are the programming languages like C, which have been developed to support them.

Academic curricula also are focused on application-development languages that are primarily used in sequential form. It can be argued that applications like search engines and data aggregators can really benefit from the huge amounts of processing power that they can gain from moving to multicore servers. The problem, however, is expanding the scope of multicore systems beyond specific applications as well as making them more general purpose. Again, the aim is to help the platform proliferate across different applications and markets.

In the traditional model, the operating system and the hardware adaptation layer (HAL) provided a layer of abstraction between the platform and the application developer. With a multicore platform, that separation becomes fuzzy. To make optimum use of the system, the application developer has to be able to take advantage of the multiple processor cores that are available. He or she also must be able to move data between the following: cores; cores and memory locations; and local and shared resources. The developer therefore has to be able to program at a high level and program concurrently. See Figure 1.

Chip-design and embedded-software-development tools have gone through a multitude of automation cycles. Yet a high-level programming model, which abstracts away enough of the complexity of the lower layers to allow the application developers to optimize the application, is still not available. Although new platforms like the Cell Processor have been developed, they are being used for specific applications in which the architecture is understood well enough to be fine tuned for that particular application (e.g., video games).

Multicore platforms are very expensive to design and manufacture. Thus, the cost of failure is very high. A multicore platform must ship in the millions of units to be profitable. Given this fact, the software ecosystem that's built around the platform must be robust and easy to use. In addition, the platform must be easy to program.

The availability of software that was relatively easy to develop and use drove the PC revolution. Similarly, the Internet—with its huge volumes of data traffic going back and forth—drove the networking revolution. On the consumer end, the explosive growth of the mobile-handset market has driven the growth of the consumer-telecom segment. Device convergence is now spreading the revolution across the consumer-electronics markets. As new generations of devices and products come up in these markets, the demand for greater processing power is increasing. Each device is supporting more functions than the previous one.

Many of the multicore platforms that have come from the leading semiconductor companies target applications that are mostly homogeneous environments. In the consumer-electronics market as well as other verticals, however, the majority of the systems used today are asynchronous, heterogeneous systems. They require some predictable degree of response in a deterministic manner.

Embedded systems are proliferating in all verticals. In this cycle, the world of consumer devices—the current driver of the semiconductor revolution—is made of mostly embedded devices. Those devices are mobile phones, MP3 players, set-top boxes, and other devices that are expected to increase in functionality and feature sets with each new generation. Meanwhile, the cost of designing these platforms is going up tremendously. Clearly, failure isn't an option. The focus is no longer purely on execution speed and Dhrystone and Whetstone benchmarks. Speed alone doesn't guarantee the success of a platform.

The key to success lies in the software environment and in developing the right kind of software tools and operating systems to support these new platforms. Software issues must be considered at the system level itself. The historical trend of completing the hardware design before throwing it over the wall to the software groups breaks down in the current context. The problem is the design complexities that are inherent in developing the new generation of systems. Attempts are being made to develop tools to help with the design of such multicore systems at the architectural level, which includes hardware-software partitioning, testing, and verification. But these efforts are fragmented and piecemeal.

The other issue is the age-old marketing problem of time to market. In a competitive environment, the company that's first to market grabs marketshare and mindshare. To maintain that initial momentum, however, the platform has to become a mainstream product and generate sufficient revenue to sustain the next generation of product development. Without a good software environment, achieving this goal becomes next to impossible.

In the old days of the semiconductor industry, semiconductor companies were responsible for the hardware platform as well as the operating system and some development tools. The compiler and the debugger, which are essential tools in the programmer's arsenal, shipped with the hardware platform. Over the years, the evolution of the semiconductor supply chain meant that design- automation-tool providers supported semiconductor and systems vendors through third-party tools and support networks. With this new generation of products, however, the design-automation tool vendors are behind the curve. One may even speculate that the multicore revolution may be driving a consolidation back to the era when the semiconductor and systems companies were responsible for both the hardware and software.

Daya Nadamuni is a market analyst and consultant covering the design automation tools, middleware and application markets. She keeps her trusty crystal ball by her side at all times and welcomes questions and comments at dnadamuni@yahoo.com.