Software Limits Multi-Core ICs, Panelists Say

SANTA CLARA, Calif. — Multi-core ICs promise efficiency and performance, but will require new programming models that hide software and hardware details, according to panelists at the GSPx 2005 conference here Tuesday (Oct. 25).

With multi-core ICs, said Daya Nadamuni, chief analyst at Gartner Dataquest, "software is both the problem and the opportunity." She noted that systems-on-chip (SoCs) have not only hardware, but also a hardware/software binding layer, real-time operating system (RTOS), middleware, and applications software. Miss any of these components and you have problems getting to market, she said.

Nadamuni said that SoCs comprised 16 percent of the ASIC market and 31 percent of the ASSP market in 2004, and are expected to show rapid growth. The largest consumer, she said, is the handheld market, with automotive electronics expected to be a growth area in the future. But success depends on managing a "software explosion," she said.

The price of failure can be high, Nadamuni said. In China in 2004, she said, 65 percent of sub-$100 DVD players were returned, many due to software failures.

Steve Krueger, core IP architect at Texas Instruments, discussed his company's OMAP 2420 multi-processor SoC, which includes an ARM 11 general-purpose processor, a programmable DSP, and a number of special-purpose processors for such tasks as video and graphics. He noted that special-purpose processors can be 10 to 20 times more efficient than general-purpose processors, and can provide the required performance for fewer MHz than general-purpose processors.But there's a price. IP integration is a big issue, Krueger said. Another challenge is a conflict between asynchronous IP interfaces and strict real-time requirements, which tend to conflict with asynchronous behavior. Power management is also a challenge, and has led TI to segment chips into a large number of power domains with unequal supply voltages. A final challenge is memory performance and coherence.

"The principal problem of multi-core is how you map software applications into increasingly complex hardware," said Mark Lippett, CTO of Ignios Ltd. "The challenge is the programming model and the efficiency it delivers."

A good programming model, said Lippett, is all about transparency — that is, hiding hardware details from the programmer. He said programmers shouldn't have to worry about scalability, performance, access, location, failure, migration, or concurrency. And yet, he noted, "we cannot sacrifice real-time efficiency to achieve this level of abstraction."

What's needed, said Lippett, is a "platform abstraction layer" to map software applications to hardware. Ignios provides such a layer in its SystemWeaver product, he said.

Simon Davidmann, CEO of startup Imperas, noted that chip design methods that worked well with ASICs fall down when software is a big part of the functionality. Multi-core design, he said, is pushing us towards a "sea of processors" architecture that may involve hundreds or thousands of processors.

Today, however, software written for one processor is almost impossible to port to another, he said. Programming models are aimed at single processors and single threads. What's needed, said Davidmann, is a programming model that can abstract hardware and software details away, and a way of automating the compilation of applications onto platforms.Sven Brehmer, CEO of Polycore Software, said he's been in the embedded programming area for 20 years and that multi-core ICs are the biggest disruption he's seen during that period. Suddenly, he noted, designers have to worry about moving data between cores, managing different types of connections, coping with shared and local resources, and perhaps juggling multiple operating systems.

"We need to find ways to incorporate these problems into application development, and keep it relatively simple without sacrificing performance," he said. Polycore, he said, provides a "communications infrastructure" that can provide such an abstraction.

An audience member challenged panelists by asking why an abstraction layer is needed, given that an RTOS has knowledge of the hardware and the programmer has an understanding of the RTOS.

An RTOS is based on instances of processors, responded Ignios' Lippett. What's needed, he said, is a way of talking to classes of processors. An abstraction layer is needed, he said, to manage parallelism, permit retargeting of applications, distribute the load, and manage the power.

"The reality is that if you take away abstractions, you can find an efficient solution to any problem," Lippett said. "The problem is that we don't have that luxury."0