NATIONAL PROVIDES DEBUGGING SOLUTION TO
TIGHTLY-COUPLED MULTI-PROCESSOR APPLICATIONS

By Rafi Kedem

Applications and 3rd Party
Program Manager
Core Technologies Unit
National Semiconductor Corp.
Santa Clara, Calif.

oday's embedded systems designs often incorporate more than one microprocessor. These are generally very tightly coupled and run in parallel, handling diverse tasks simultaneously. A good example is the FAX/scanner/copier/printer integrated into a single office machine. In that product, the main CPU controls the scan/copy function and drives the scanner or printer engine, while a DSP on the same die handles the FAX modem transmit/receive modulation/demodulation tasks. Some designs even use tightly coupled processors residing on multiple boards, such as wireless handsets and base stations like DECT wireless systems. Even though the two devices are coupled by RF signals, they operate in real time with a tight communications protocol between the processors in each.

Designing these machines is a challenge, not only because of their complexity, but because debuggers have typically not been tightly coupled. Further complicating the debugging is that the multiprocessors might be co-located on a single die, share a single printed circuit board, or be on two (or more) separate — but coupled — circuit boards. Debugging these designs means that you must use separate debuggers and pay close attention to deal with failures and exceptions to ensure you know the status of each processor. Without that knowledge, failures induced by actions taken by the other processor can be elusive and consume a great deal of product development time.

Not only are the debuggers typically incapable of operating in a highly coupled and parallel environment, they also have to deal with multiple hardware connections to the device being developed. A recent development at National Semiconductor makes debugging complex embedded systems much easier, saving time in the process and allowing you to get your product to market faster.

Debugger Communication Interface
National Semiconductor’s CompactRISC™-based Debugger Communication Interface (DBGCOM) enables multiple cross-debuggers, running on a single host PC with Windows 95 or Windows NT, to interact with multiple cores integrated on a single chip, or multiple microprocessors on a single board or multiple systems boards.

The DBGCOM was developed for use with the National Semiconductor’s CompactRISC family of cores, the CR16 and CR32. National worked with Signum Systems and IAR Systems to interface the DBGCOM into their debugger products, resulting in complete, multiple-core development and debugging systems.

Simultaneously, multiple debuggers communicate with the DBGCOM, which provides a single, standard API to all of the debuggers. Isolating the debugger from the physical connection eliminates the need for the debugger to support multiple hardware interfaces, which would normally require a new release of the debugger software for each new interface introduced. It also unburdens the debugger from knowing about and dealing with the actual hardware interface and its associated software drivers. For example, most of the debuggers currently on the market will require a new release once the Universal Serial Bus (USB) becomes a standard interface.

Figure 1 illustrates how the debugger can be used with any physical hardware interface, provided that the appropriate software driver exists, allowing much greater flexibility. The debugger does not actually "know" what hardware is present; it can even be used with a simulator running a model of the target board with its processors and system peripherals.

Decoupling the debugger from the hardware interface has the added advantage of allowing more rapid development of future debuggers. Only a single, standard interface to the DGBCOM API is required instead of drivers for any number of communication interfaces.

The processors in Figure 1 run a ROM monitor residing on the target board (TMON) to communicate with the debugger through a predefined API, which enables debugging. The only parameters that the debugger must know are the actual processor architecture, the TMON API, and the DBGCOM API.

Simple Configuration
The DBGCOM drivers are installed in the host PC running Windows 95 or Windows NT as a Dynamically Linked Library (.DLL). The debugger loads the .DLL and integrates the DBGCOM directly into its own user interface. This provides you with a smooth, seamless operating environment.

The DBGCOM installs new hardware connections and drivers much the same way that Windows installs printer drivers. You are not concerned with the actual driver required for a particular printer: you simply pick the printer drive from the "Add Printer" dialog box and Windows selects the proper driver and automatically installs it. Then, you can select from any installed printer by point-and-click method from a menu of those available.

A debugger communicating through the DBGCOM dynamically links to the DBGCOM API and invokes the DBG_Get_Device_Names() function to determine which communication device drivers are available. DBG_Get_Device_Names() returns a list of all available device drivers to the debugger software, using the name defined by the user when the drivers were installed. Once all the driver names are known by the debugger, you select a communication interface (by name) and a processor ID associated with the debugger session. The debugger then associates a session window with a particular processor in a multi-core chip, or to a single processor. This is very similar to the way you select a printer from a Windows 95 application (i.e. "Printer Setup").

DBGCOM Operation
When used to debug multiple-processor designs, the DBGCOM allows you to open several multi-threaded virtual communications channels, one to each of the processors in the product. Since the connections are independent of the debuggers, the actual location of the processors is immaterial: they can be on the same die or separate boards. Even the simulator "looks" the same to the debugger.

Figure 2 shows two windows from the Signum Systems’ Chameleon Debugger™ GUI. The "Systems Configuration" window allows target processors, such as the CompactRISC to be added and configured. The "Interface Configuration" window allows you to configure the DGBCOM processor session.

DBGCOM is reentrant so that you can invoke the program multiple times simultaneously. Each one is transparent to the other callers of the program. This allows several debuggers to be active, communicating with DBGCOM at the same time. In fact, you can use different debuggers at the same time depending on the needs of the product being tested and your own preference in debuggers for a particular application.

In a traditional debugger configuration with multiple CPUs, a separate debugger would be opened for each CPU. Each of these debuggers would then have a separate, linear connection to the device under test. Communication between debuggers is non-existent in this configuration, requiring you to provide a high level of interaction.

DBGCOM provides the intelligence to allow multi-threading and communications between debuggers. Rather than a linear connection to the devices tested, DBGCOM allows for a "star" or peer-to-peer connection with the DBGCOM residing at the center of the star coordinating debugging activities and communication, depicted in Figure 3.

Debugger Operation
Trying to run multiple debuggers in the traditional linear fashion presents a cluttered and difficult-to-use array of open windows, even on a large computer monitor. Worse, its nearly impossible to coordinate the debugging and monitor status of each of the processors being tested. With DBGCOM and a compatible debugger you can configure a simple and useful window detailing all the status information you need.

Two debuggers are currently available which operate with the DBGCOM. IAR Systems offers a single core debugger that supports the CompactRISC family of cores. The IAR debugger incorporates the DBGCOM through its .DLL and allows seamless use. You can open multiple sessions of the debugger, and even run the IAR product with other company’s debuggers at the same time through DBGCOM.

Signum Systems also offers a debugger compatible with DBGCOM. Signum’s debugger is enhanced to provide multiple-core debugging for the CompactRISC family. With this debugger a single window can display status and configuration information about multiple cores at the same time. You can run emulations and even single step through instructions in a coupled debugging environment.

You configure the debugging environment to display the information pertinent to the debugging task at hand. You can show register status, disassembled code, and a variety of other important parameters. Figure 4 shows a typical screen configuration using the Signum multiple core debugger with DBGCOM.

When debugging, breakpoints set for one controller are interactive, allowing an error condition in one processor to trigger a breakpoint in another processor’s debugging routine. Thus, the resulting close-coupled debugging environment allows development and test of multiple closely-coupled processors in virtually any application. No single-channel debugger without DBGCOM allows such synchronization.

Conclusion
As embedded designs become more and more complex — incorporating multiple processors executing specific tasks, and even mixing analog and digital signals — debugging tools must be provided allowing closely-coupled integration and emulation to adequately integrate the designs in reasonable time periods. The DBGCOM now makes this possible.

Multiple debugging sessions on multiple processors can all be run at the same time with status and other parameters displayed in an easy-to-use window. The virtual sessions in the DBGCOM allow breakpoints to be set to trigger between coupled processors, thus providing fast and accurate debugging across the entire multi-processor system.

The DBGCOM also eliminates the physical hardware connection between the debugging tool and the application board being integrated. Debuggers can be developed more rapidly without necessitating handling of diverse protocols, just the DBGCOM API. Because the debugger no longer is aware of the physical connection, it can even be used with system simulators transparent to the debugger.

DBGCOM was developed specifically for use with National’s multi-core system-on-a-chip and multi-core CPU/DSP products. The ability to handle multiple processors on a single chip makes the DBGCOM extremely versatile and useful with a wide variety of debugging tools for embedded processors, in a wide variety of applications.

• • •

CompactRISC is a trademark of National Semiconductor Corporation.

Rafi Kedem is the Applications and 3^rd Party Program Manager for National Semiconductor Corporation’s Core Technologies Unit in Santa Clara, California. Rafi has more than 13 years experience with embedded applications, such as FAX machines, digital answering machines, modems and multifunction peripherals. In addition, Rafi has extensive experience in general purpose microcontrollers and RISC processors in the area of applications and development tools.