Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Tools help harness multicore power

Posted: 01 Jun 2006 ?? ?Print Version ?Bookmark and Share

Keywords:Bernard Cole? Embedded Systems Design? silicon? eda? multicore processor?

The move toward multiple processors on a single chip, on a single board and in a single system to provide more features and speed at lower power may have solved certain embedded hardware design problems. But for software developers and vendors, embedded multiprocessing presents a daunting set of challenges.

In contrast with the familiar balanced, symmetric and homogeneous multiprocessing environment of servers and large computer systems, the embedded and mobile-appliance world can require the developer to program a heterogeneous and unbalanced mix of RISC, DSP and network architectures operating asymmetrically.

At recent conferences, hardware developers have bemoaned the lack of suitable tools and building blocks for software development in multicore environments. Many embedded software vendors say that they have devised solutions to most of the immediate problems. The big question is where to go next as the cores used in multiprocessing designs increase in number and heterogeneity.

"As more processing elements are embedded into the silicon, the level of software complexity is outstripping the capability of traditional embedded-software tools to efficiently develop application software code and to manage the system," said Sven Brehmer, president and CEO at PolyCore Software Inc.

Too many tools
The problem is not a shortage, but a surfeit of tools and building blocks, said Robert O'Shanna, software engineering manager at Texas Instruments Inc. (TI). "With diverse solutions and no commonalities among themno industry standards on methods and proceduresvendors are beginning to appear with a wide range of OS- and hardware-specific solutions," O'Shanna said. "And those offering some degree of platform independence require the use of frameworks and methodologies that are unfamiliar to many developers."

The vendors themselves are responding to a multiplicity of developer questions: At the operating system level, in a multiple-CPU environment and at the application level, how do you efficiently write code for multiple targets? What is the best mechanism for managing multiple operating systems on multiple CPUs? How do you debug in this environment?

For the first two questions, the answers themselves are multipart: the use of message-passing mechanisms to hide the CPUs and the partitions that must be managed; the use of a common application programming interface as a target; the development or adaptation of system-level modeling tools to sort out software implementation complexities; and a shift from traditional, familiar, sequential procedural-programming languages to functional programming and higher levels of abstraction.

Joseph Dubin, multicore software product manager at Freescale Semiconductor Inc.'s Developer Technology Organization, said the issues, while complex, have been faced before.

"Multiple-CPU environments are common at the board and chassis level, and numerous techniques for managing software in that environment have emerged," he said. "What's different now is that some applicationssuch as handheld and some embedded consumer appsare turning to the use of multiple CPUs on the same chip. While it will require some modifications of techniques, there is a clear path with few unknown problems that cannot be addressed."

Horse of another color
However, PolyCore's Brehmer believes that the adoption of heterogeneous multiprocessing for small-footprint consumer devices poses a set of problems that differ in kind and degree from those encountered elsewhere.

"While there are some applications in networking and blade environments where multiprocessor environments are possible with existing tools, many embedded designs in consumer and mobile are constrained because of power requirements to operate using an asymmetric model, to get the most efficient use of the silicon," Brehmer said. "Additionally, they require different types of processorsmultiple instantiations of RISC and DSPdifficult to operate in SMP [symmetric multiprocessing] mode."

There is also the problem of software partitioning, which is crucial in multiprocessor designs. "Too much communication between multiple CPUs negates the advantages of multiprocessing," said Brehmer. "Currently, most software partitioning in mainstream applications assumes a subprocessor configuration in which the application space is divided into two main partsthe control and user interface, and non-stop signal processing."

Such models are built around shared memory architectures in which partitioning is done at an early stage. In many consumer designs, partitioning assumes that the RISC engine is the main processor and the DSP configured as a peripheral. "The disadvantage is that although the subprocessor [DSP] has a substantial portion of the computing tasks, it is blocked more often, waiting for commands from the main processor," Brehmer said. "That negates much of the advantage of parallel processing offered by the use of multiple processors."

John Carbone, VP of marketing at Express Logic Inc., acknowledged that the embedded-software industry will have to address many issues over the long term, as application requirements and fabrication technology limitations force the use of more than two or three CPUs on a chip. "But near-term," he said, "there is much we can do with what we know now by carefully selecting the hardware platforms and programming models we use."

A problem in environments with a mix of DSP and RISC engines is that it is difficult to use SMP to balance loads and share application processing over multiple CPUs.

One problem in environments with a mix of DSP and RISC engines is that it is difficult to use SMP to balance loads and share application processing over multiple CPUs. At the hardware level, Carbone said, this problem is ameliorated by two trends. The first is the creationby companies such as Analog Devices, Atmel, Freescale and TIof so-called converged architectures combining DSP and RISC operations into one architecture. The second is the emergence of brute-force RISC architectureswith some additional DSP instructions and pipeliningthat throw MIPS at the problem.

Either approach allows for a nice SMP environment in which the programmer can assign tasks without being concerned whether they need be targeted at RISC cores or DSP cores. In the brute-force architecture, using three or four CPUs addresses many DSP requirementsalbeit less efficientlyand not with a 3-4x performance enhancement, but with a more modest, two- to threefold boost.

In such quasi-SMP environments, existing OS and RTOS can be retained, albeit with some modifications, said Carbone.

While it does not yield the performance and power consumption improvements that a fully tooled asymmetric multiprocessing environment might enable, the modified SMP configuration allowed by ThreadX yields improvements on the order of 60 percent to 85 percent, Carbone said. And it does so without requiring that the programmer abandon the familiar single-CPU, single-program environment.

Spare, lean RTOSes
However, not all RTOSes "are amenable to this kind of modification," said Dave Kleidermacher, Green Hills Software Inc.'s VP of engineering. "If they are top-heavy with services and functions and are already pushing hard to maintain deterministic operation, they will have no headroom to handle the modifications that must be made. What you need are spare, lean RTOSes with extremely small kernels, and with thread and interrupt structures that are well-adapted to operations in hard real-time environments."

Eventually, said Express Logic's Carbone, the embedded-software industry will have to develop tools appropriate to writing code that efficiently operates in heterogeneous, asymmetric computing environments. "We have no choice," he said. "Where the builders of the CPU hardware go, we must follow with the tools and frameworks that allow developers the simplicity of a single- CPU program model but allow development of code that efficiently operates on any CPU in a multiprocessing environment."

Until something better comes along, however, the trend is toward message-passing middleware frameworks that manage transactions among multiple CPUs and multiple RTOSesor multiple instantiations or images of a single RTOSbut present the developer with a single, common API.

- Bernard Cole

Article Comments - Tools help harness multicore power
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top