Microprocessor Debugging: It's Not Just Threads Anymore

July 9, 2001
Multicore system-on-a-chip (SoC) designs and multiple-processor systems push developers and debuggers to the limit. These designs are cropping up in various embedded products, from high-performance network switches with dozens of identical packet...

Multicore system-on-a-chip (SoC) designs and multiple-processor systems push developers and debuggers to the limit. These designs are cropping up in various embedded products, from high-performance network switches with dozens of identical packet processors to tiny MP3 players that combine DSPs with general processor cores like ARM and ARC.

The hardware designs are complex, so designing and debugging these systems from a hardware standpoint is a difficult task. But it pales in comparison to software development as interprocessor communication grows. Timing and race problems associated with communication-oriented applications in the past are now common in more general applications because of the distribution of processing power. The designs provide significant performance gains but with increased complexity in application design and debugging.

Multiprocessor system designs aren't new. But hardware implementations, such as symmetrical multiprocessing (SMP) servers, don't really require new debugging techniques because the system appears to be one logical processor from a debugging standpoint. This isn't the case for a network of processors where each processor is distinct in terms of operating system (OS) and applications. Very similar to embedded multiprocessor systems and multiprocessor SoC designs, this type of environment is common with networked applications.

The main difference between a network and a board- or chip-level multiprocessor system is processor-to-processor communication speed. Networks run at Ethernet speeds, while board or SoC designs run at memory speeds. In fact, shared memory links are common like dedicated, point-to-point links. In all of these situations, a developer must contend with distinct processors.

Mixing Processors The problem is typically more complex due to the differences among processors. A common configuration is a general-purpose processor (GPP) coupled with a digital signal processor (DSP). A typical application is an MP3 player. The GPP handles the housekeeping, such as flash-memory management and the user interface, while the DSP handles the conversion of streaming data to audio output. Here, the operating systems for the two processors will vary. It usually means that most of the development tools will differ, including the debuggers. The last point is changing, though. Cross-platform debuggers also are becoming multiplatform with multiple processor support.

Prior to advanced debuggers, a developer would have to debug multithreaded programs on two processors and run two debuggers. That generally isn't a problem, but typically the debuggers are completely independent from each other. The lack of communication between the debuggers means a lack of breakpoint coordination and event recording. This can be a problem when dealing with applications that span processors.

Take for example a program on a GPP that delivers the MP3 stream to another program on the DSP. If the GPP program hits a breakpoint, then the DSP program will probably need data before the developer can halt the DSP using the associated debugger. Granted, simultaneous halting of processors can't happen without hardware support. But the process can be streamlined to a small fraction of a second if the debugger performs the action. A breakpoint table usually groups related tasks so that actions will be performed on the whole group. New multiprocessor debuggers accomplish exactly this.

Multiprocessor Debugging Tools Getting debuggers to handle multiple processors is no easy feat. The Multicore Debug System (MDS) from Protel's Tasking group (www.tasking.com) uses one approach. MDS fits between the debugger front and back ends to coordinate actions among the Tasking debuggers. The debuggers are enhanced to take advantage of the coordinated operations and event notification. The developer still deals with distinct debuggers, but they're tied together, as is the hardware.

From Green Hills Software (www.ghs.com), the Multi 2000 debugger takes an integrated approach to the debugger. A developer can open distinct windows for debugging information and control associated with individual tasks regardless of what processor the tasks are running on. The debugger also provides a coordinated breakpoint system where breakpoints can implicitly or explicitly trigger other actions, such as enabling other breakpoints or stopping other tasks. And, the Multi 2000 debugger supports the concept of breakpoint groups.

The Mentor Graphics (www.mentor.com) XRAY debugger has handled multiple-board debugging, and it retains this architecture for multiple-core debugging. The common interface supports a variety of processors and cores, so a developer only has to learn processor and OS-specific details when a new platform is incorporated into a design. As with most multiprocessor debuggers, XRAY supports multiple hardware probes.

Multiprocessor debugging tools still need to address some difficult problems. For example, time-stamped event logging requires synchronized timers if event logs from different processors are merged. Likewise, most debuggers don't address communication links very well, especially network links like TCP/IP running over Ethernet. Debugger improvements in these areas would be greatly appreciated.

See associated figure

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!