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

Dearth of tools, expertise slows multi-core progress

Posted: 16 May 2007     Print Version  Bookmark and Share

Keywords:debugging multi-core ICs  tool support for multi-core  multi-core solutions 

Tool support for multi-core programming is 'still in the dark ages,' says Agarwal.

The lack of parallel-programming tools and expertise among embedded designers is threatening the progress of multi-core architectures. "Though the solutions are emerging, the tools needed to program and debug multi-core ICs are in the "dark ages," said Anant Agarwal, a professor of electrical engineering and computer science at the MIT.

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 multi-core 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 multi-core?" he asked.

Driven by performance and power concerns, multi-core ICs are fast finding favour among designers—so much so that observers warn that in a few years, multi-core 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 multi-core. 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 multi-processing, 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 multi-core application development.

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

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

Heterogeneous multi-core 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 multi-cores, 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 start-up Imperas Inc., presented four "axes" for categorising multi-core 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 multi-core 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, parallelisation and optimisation. What's needed, he said, is a programming model that makes it possible to create parallel applications, optimise the mapping of those applications onto parallel hardware and gather data to guide the optimisation decisions.

Programming models
Providers are promoting varying approaches to multi-core 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 multi-core 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, multi-core 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

Comment on "Dearth of tools, expertise slows mul..."
*  You can enter [0] more charecters.
*Verify code:


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


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top