Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

Turn on the lights and the cockroaches run away. This often seems to be the way to deal with programming bugs as well. Bring out the debugger or trace tools, and the problem goes away or remains difficult to locate.

While application bugs don’t really react like real bugs, changing the state of an application’s environment does affect how buggy code responds. This is one reason why tools that impose no overhead on an application are highly valued. In the past, external trace and debug facilities let designers probe the system without impacting the performance and, hence, the system’s real-time response. The problems these days, limited pinouts and higher processor-speed limits, prevent designers from bringing out the necessary signals to provide low-overhead debugging facilities.

There have been significant improvements in moving debugging support onto the chip as well as in providing more detailed and lower-overhead debugging features. But there is often a tradeoff with respect to system power consumption and chip real estate.

NEW WAYS OF DEBUGGING
Different approaches are being used to improve performance and reduce the overhead that’s associated with conventional techniques such as tracing (see “Compact Tracing With 32-Bit Microcontrollers” ED Online 17422).

MIPS FS2 Division’s Hot Spot Analyzer employs statistics. It tracks the program counter (PC), but it doesn’t record all states. Instead, the PC is captured periodically and sent out the JTAG port (see the figure).

The data is captured at regular intervals and retrieved by the Hot Spot Analyzer (HSA) application, a MIPS sampling feature built into the 24K, 34K, and 74K MIPS cores. The HSA also is an Eclipse plug-in that works in conjunction with other debugging tools. The system primarily profiles operating systems and drivers such as the Linux kernel and loadable modules.

STATISTICAL DEBUGGING
The HSA only works when there is enough information, so this approach isn’t a matter of running a few thousand instructions. It’s just the opposite of most breakpoint or trace approaches. Furthermore, it will provide a statistical usage map that’s useful in checking code coverage and for finding areas of code with lots of activity.

Compared to conventional tracing and logging systems, it requires minimal overhead and applies to long periods. It will typically be used for identifying areas for optimization, but it is a useful debugging tool as well since it provides additional insight into the operation of the system.

MULTICORE DEBUG CHALLENGE
Multiple cores will be available to a wider range of developers. And as these cores get more work to do, they will require more debugging. Developers can implement statistical approaches that are similar to HSA, which is a relatively trivial task in software when additinal cores are available. Likewise, FPGAs offer yet another platform to take advantage of unused chip resources for improved debugging and reliability.

MIPS • www.mips.com