|
I know this is an EDA software blog, but sometimes it's very hard to divorce hardware and software design. That's especially true with heterogeneous multicore SoCs. How do you write a program when you have an ARM core, a DSP processor, and another specialized processing unit or two?
The Multicore Expo in Santa Clara, Calif. March 27-29 will shed a spotlight on programming and debugging challenges for multicore devices. The first challenge is remembering that the two and four-core SoCs we're seeing today are the tip of the iceberg. Many observers foresee SoCs with hundreds or even thousands of processors in a few year's time.
Heterogeneous architectures will be commonplace, and traditional shared busses will give way to network-on-chip approaches. Existing programming and debugging models face dramatic change, and work must begin now, not two or three years from now.
Debugging tools need to present a single view of an SoC's multiple processors, so developers can see all the interactions between processors. The technical challenge is steep. As a presentation from ARM will note, multiple devices with different protocols in different clock domains must trace at the same time through a single trace port. SoC debug components must share triggering, breakpoint and profiling information, and development tools must access multiple debug components through a single interface while parts of the SoC are powered down.
Program errors are difficult to provoke and recreate, and thus to reliably resolve, because multicore SoCs are inherently non-deterministic, notes a presentation from Virtutech. Re-running a failed test case does not necessarily recreate a problem, and the intrusive effects of traditional debug techniques tend to hide errors. One possible remedy is to use a simulated model of a multicore system instead of physical hardware.
There's a lot of work going into the standardization of the interfaces, methodologies, and features needed for multicore debug. A Multicore Expo panel will report on such efforts within the IEEE Nexus Forum, IJTAG (IEEE P1687), OCP-IP, Multicore Association, Spirit, and Eclipse consortiums.
Programming is also a huge challenge, given the inherent parallelism of multicore architectures. A presentation from RapidMind Inc. notes that multicore processors introduce issues of synchronization, deadlock, load balancing, and non-determinism. Multicore architectures also put additional pressure on the memory system, since the gap between off-chip bandwidth and on-chip processing power is growing exponentially. One approach to scalable performance exploits data parallelism.
It seems to me the big challenge is bringing parallel programming to the embedded world. For the most part, embedded developers don't have the expertise, and they don't have compilers that can automatically extract parallelism without user guidance. We'll need to take the best of what's available today in the enterprise software world and bring it on over to the embedded space. If the current providers of embedded software development tools and real-time operating systems can't do that, new providers will emerge.
Posted by Richard Goering on Mar 23, 2007 07:27 PM in EDA Software
|
RSS
RSS| 
Digital| 
Mobile
