2 I Seven Lifesaving Tips for Multi-core Debugging

If you haven’t worked on a multi-core project yet, you probably

will soon. For decades developers relied on miniaturization,

higher clock speeds, and design improvements on single-core

chips for software speed-ups. Multi-core processors provide

more functionality in a smaller, tightly integrated footprint,

which means they draw less power—a big win for makers of

embedded systems. As the gains from going multi-core

continue to become more competitive with traditional

single-core architectures, more companies are making the

switch. In fact, according to VDC Research, 61% of embedded

engineers expect they will be using multi-core or multiprocessor

architectures in their development projects by 2012.

More than 60% of embedded engineers

expect to be using multi-core or

multiprocessor architectures in their

development projects by 2012, according

to VDC Research.

But multi-core is fundamentally different from traditional system

design. The things we need to think about as designers or

developers are more complex, and while the rewards of

migrating to multi-core are great, there are common traps to be

aware of. Some are technical, involving new programming

complexities and debugging techniques, while others have

more to do with project scope and the risks to budgets and

timelines. The risks are enough that fully a quarter of multi-core

embedded design projects miss meeting their deadlines and

their functional targets by at least 50%, according to Embedded

Market Forcasters.

Fully a quarter of multi-core embedded

design projects miss meeting their

deadlines and their functional targets by

at least 50%.

Knowing about and avoiding these pitfalls can make the

difference between a trouble-free development cycle and one

that is plagued by problems. So here they are: the top seven

issues you need to know about when you make the switch to

multi-core.

1. Breakpoints Can Break Your Debugging

If you do multithreaded programming, you know that

thread-aware debuggers are essential to provide meaningful

insight into which thread was executing when a breakpoint was

reached and how to stop execution in a synchronized way. On a

multi-core system, breakpoints are even more complex because

there is no guarantee that the other processor cores will stop

simultaneously. In the multi-core world, a debugger needs to

have breakpoint monitoring and synchronization across

processors or cores, otherwise thousands of instructions may

execute before the system is halted. It is very common when

halting a core at a breakpoint to lock up the other cores.

Of course, you can use a JTAG (Joint Test Action Group)

interface, but not all JTAG implementations are equal; and when

migrating to a multi-core architecture, it is important to

understand the differences. One of the great advantages of

JTAG is the ability to truly stop a processor, allowing accurate

inspection of its state at a given point in program execution.