Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Controls/MCUs
?
?
Controls/MCUs??

Lack of tools, expertise stalls multicore progress

Posted: 16 May 2007 ?? ?Print Version ?Bookmark and Share

Keywords:debugging multicore ICs? tool support for multicore? multicore solutions?

Tool support for multicore programming is 'still in the dark ages,' says Agarwal.

The tools needed to program and debug multicore ICs are in the "dark ages," according to Anant Agarwal, a professor of electrical engineering and computer science at the Massachusetts Institute of Technology, in his keynote at last April's Multicore Expo. Solutions are emerging, but the dearth of parallel-programming tools and lack of expertise among embedded designers threaten to slow the progress of multicore architectures.

Although designs studded with two, four or even eight processor cores on the same die are fast becoming commonplace in embedded applications, tool support for multicore programming is about where VLSI design tools were in the 1980s, Agarwal said.

Agarwal called for new tools, standards and ecosystems. "Who will be the Microsoft, the Cadence or the Synopsys of multicore?" he asked.

Driven by performance and power concerns, multicore ICs are fast finding favor among designers!so much so that observers warn that in a few years, multicore ICs will have hundreds of cores. Meanwhile, programmers are struggling to cope with today's designs.

"Multicore is hard," said Tomas Evensen, CTO of Wind River Systems. "There are ways to make it easier, but there's a lot of history around sequential programming that makes it hard to move to multicore. A lot of code is written in a single-threaded way, and people don't want to start from scratch and rewrite."

Multicore architectures involve multiprocessing, and to take advantage of that, parallel programming is needed. But few embedded designers have the expertise. "Parallel programming was hot 15 years ago in academic circles, and then it wasn't," said Michael McCool, chief scientist at RapidMind Inc. "There's a whole generation of programmers who don't know how to program in parallel. All programmers will have to become parallel programmers!and quickly!because all programs will be parallel."

McCool noted, however, that "compilers do a terrible job extracting parallelism." Multicore debugging is also challenging, because programmers must track interactions between cores and ferret out deadlocks, data races, memory corruption and stalls. Different processors typically come with their own debugging environments, making it tough to get one view of what's going on in the system.

New solutions
Solutions, however, are emerging. New and existing companies are rolling out compilers, software development platforms, analysis tools and debugging architectures that claim to ease!though not fully automate!the transition to multicore application development.

Various multicore architectures pose different programming and debugging challenges. Homogeneous multicore ICs, such as the ARM11 MPCore, use very similar or identical processor cores. Heterogeneous multicore architectures, such as Texas Instruments Inc.'s OMAP, use different types of processors.

Some homogeneous multicore ICs use symmetric multiprocessing (SMP), in which there's shared memory and a single OS that automatically assigns processes to different cores. With asymmetric multiprocessing (AMP), the user manually assigns tasks.

Heterogeneous multicore ICs raise a raft of programming challenges, noted Greg Davis, technical lead for compilers at Green Hills Software. Different CPUs may require different compilers, dialects and pragmas, he said, and some have "flaky tools." Auxiliary cores may have limited memory banks and must interact with a master core to swap in memory.

SMP is tightly coupled with multicores, shared memory and OS.

SMP is an attractive programming model, because some existing prepartitioned code will "just run faster," Davis said. But SMP systems may exhibit nondeterminism, inefficiency and latent race conditions. AMP provides more user control over efficiency and determinism, but results in less portable software with higher up-front costs, he said.

Frank Schirrmeister, VP of marketing for stealth-mode startup Imperas Inc., presented four "axes" for categorizing multicore systems: processors, communications, memory architectures and "specificity" for applications. All affect programming. For some types of designs, the big challenge is mapping tasks to the right processor; for others, it's runtime mapping to determine available compute space.

The shared-bus systems used for many multicore ICs are difficult to program and debug, and prone to deadlocks and data races, Schirrmeister said. And the choice of memory architecture affects task execution times, he said.

Multiprocessing presents three major challenges, Schirrmeister said: partitioning, parallelization and optimization. What's needed, he said, is a programming model that makes it possible to create parallel applications, optimize the mapping of those applications onto parallel hardware and gather data to guide the optimization decisions.

Programming models
Providers are promoting varying approaches to multicore programming. For SMP systems, Posix threads and processes provide a way to add concurrency to programs, said David Kleidermacher, Green Hills Software CTO. He advocated "partition scheduling" at the application level rather than the thread level as a way of managing CPU execution time.

MIT's Agarwal said that Posix threads will do in the short term, but they offer no encapsulation or modularity. A more promising concept, he said, is one that's already used for ASIC design: streaming data from one compute unit to another.

Streaming is fast and efficient and is similar to the sockets used for networking applications, Agarwal said. A "socketlike" stream-based API could benefit multicore devices, Agarwal said, noting that the Multicore Association's proposed Communications API standard is such an interface.

RapidMind, which provides a software development platform for the IBM Cell Broadband Engine and Nvidia graphics processor, advocates a programming model called "single program, multiple data." It includes single-instruction, multiple-data concepts, but unlike SIMD, it doesn't assume a constant time per kernel.

"This model lets you think in parallel and express locality," said McCool. "It's deterministic and safe. You can't get deadlock or race conditions."

Regardless of the programming approach, multicore developers will need analysis and debugging tools. According to Wind River's Evensen, they will need hierarchical profiling tools to partition code and find bottlenecks. And runtime analysis tools will help identify race conditions that can occur when multiple threads have access to the same data.

- Richard Goering
EE Times




Article Comments - Lack of tools, expertise stalls mult...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

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

?
?
Back to Top