Multicore silicon systems demand new debuggers - Opinion - Editorial

Electronic News, Sept 23, 2002 by Paul Kimelman

DSPS ARE BECOMING AN increasingly important component for embedded applications. And typically, these DSPs interact with conventional microcontrollers (MCUs), forming multicore SOC devices.

The evolution of multicore SOCs having both a DSP and MCU has placed critical demands on conventional debuggers. To serve as effective tools, the latest generation of debuggers geared for multicore SOCs of this type will need to be equipped with a number of advanced features.

First among these features is the ability to debug both the DSP and the MCU simultaneously in a single session and from within one tool. This includes the ability to synchronize execution among multiple processors--in other words cause all processors to stop, start, and step in unison. So unlike conventional debuggers, which interact with only one processor at a time, a multicore debugger should, through a cross-core breakpoint facility, let one breakpoint on any of the cores stop selected cores in a system at hardware speeds--that is within nanoseconds of one another. By synchronizing the operation of all cores and allowing the state of each core to be examined, a multicore debugger preserves critical state information that would not otherwise be available.

A second key feature is the capacity to define particular hardware capabilities of the system, including the type and layout of memory, and to display memory-mapped peripherals, registers, and memory locations of interest. Called extended target visibility, this feature defines memory types and understands memory subsystem behavior to provide information about the system state.

In addition, extended target visibility enables the debugger to display interpretative descriptions based on the values of complex or cryptic bit fields. In this respect, the debugger acts as a form of documentation to assist the developer by reducing the chance of errors in interpreting and manipulating those fields.

As part of this feature, a register pane should be available as a quick access window to target information. With it, a designer can dynamically customize the display of information about specific chips, boards (or both) as well as change with the state of the target.

A similar feature is the ability to display data in a rich and meaningful way enabling the debugger to know, for example, if a processor is running a real-time operating system as well as show internal states of an ASIC or a library, or the states of frames in a frame grabber, or the details of multiple fast Fourier transforms (FFTs).

Moreover, this feature would exhibit operating system awareness to display various resources in the operating system after execution halts. These resources include threads, processes, libraries, semaphores, timers, event flags and queues. With this capability, coupled with active control and the use of threads, designers are able to debug and tune their applications at the task level and monitor operating system resources.

Still another key feature is trace, including profiling, and analysis, which is the ability to collect information in a nonstop environment for analysis later. This feature preserves data that would otherwise be lost by stopping the processor.

In addition, the debugger must be able to show signal information graphically, including the capacity to run FFTs or power spectral density analyses to compare the expected results with an actual signal entering and leaving the SOC. Called visualization, this feature can display raw data to show dB scale charts or decoded MPEG-4 images.

Finally, the debugger's usefulness must extend from early prototyping to final test. Among the required abilities for this are the capacity to debug optimized code as well as code programmed in ROM, PROM and-flash memory, and the ability to write to flash memory, use ROM breakpoints and monitor a running system without intrusion.

The debugger should also take advantage of any debug hardware provided by the processor, including--but not limited to--extended breakpoints based on data address and value matches, ROM breaks, special processor-specific tests, on-chip trace, access to extended visibility and back-channel mechanisms as well as the ability to handle back-channel mechanisms for application-specific logging and test.

Paul Kimelman is the technical architect at ARM Ltd.