On-chip debugging reaches a nexus
Debugging high-end embedded applications is no longer static. Semiconductor vendors, tool developers, and instrument makers have combined to support the Nexus standard, which relies on on-chip hardware features and defines a rigorous tool methodology to assist in real-time debugging of embedded applications.
NS Manju Nath, Technical Editor -- EDN, May 11, 2000
Debugging high-end embedded applications has come a long way since the emergence of the JTAG IEEE 1149.1 standard for four-wire debugging. Thanks to an increasing number of real-time applications and shorter product cycles, debugging is no longer confined to start/stop, modify registers, single-step runtime control. Instead, today's real-time debugging demands nonintrusive, dynamic methods that rely on vendor-provided on-chip hardware.
Processor vendors have provided on-chip-debugging circuitry to ease the pain of high-end embedded development. Motorola provides background-debug mode (BDM), which in principle is an example of in-circuit emulation that keeps the processor in background mode through specialized debugging commands over a serial link. For example, Motorola ColdFire µPs (MCF202/3/4/6) come with JTAG IEEE 1149.1 support and feature a set of powerful debugging facilities. For real-time trace, ColdFire provides a parallel output port partitioned into the 4-bit processor-status (PST) and debug-data (DDATA) registers. The PST [3:0] allows the PST to transmit processor-execution status while the DDATA [3:0] displays the operand data.
In another example of on-chip assisted hardware, AMD provides the AMDebug port on its x86 µPs. AMDebug, which the company based on an enhanced JTAG interface, incorporates an on-chip trace cache, which you can use to trace a program's instruction flow. The trace cache stores 20-bit trace entries comprising a 4-bit trace code and a 16-bit trace value. When tracing a program's execution, the processor automatically places compressed trace entries in the trace cache as execution progresses. But these hardware-assisted features fall short of helping you to debug real-time embedded applications.
Also, on-chip debugging features vary from product to product even in semiconductor vendors' own offerings. For example, Motorola has at least four versions of on-chip debugging. Its on-chip-emulator (OnCE) port varies from BDM and is available on the DSP56K and DSP56300 families of DSPs. To address the need for standardization in this area, a group of processor vendors, tool developers, and instrument makers in 1998 formed the Nexus 5001 Forum, an alliance aimed at creating and defining an embedded-processor debugging interface standard for embedded-control applications. Formerly the Global Embedded Processor Debug Interface Standard Consortium, Nexus has 24 members, including founding members Motorola, Infineon Technologies, Hitachi, ETAS, and Hewlett-Packard. The alliance first addressed the debugging needs of automotive-power-train applications and now has evolved into a general-purpose interface for debugging data communications, wireless systems, and other real-time embedded applications.
In arriving at the Nexus standard interface, officially called the IEEE-ISTO 5001 standard, the Nexus forum has borrowed many of the leading-edge on-chip debugging implementations with the goals of creating the best features and using a minimum number of pins and die area. The standard is processor- and architecture-neutral and can support multicore and multiprocessor designs (Reference 1 and Figure 1). Data transfer on a Nexus interface employs a packet-based IEEE JTAG 1149.1 protocol. Alternatively, high-speed systems can base the protocol on an auxiliary port having at least two pins, thus supporting full-duplex, higher bandwidth transfers. Nexus refers to the data packets as public messages, comprising a 6-bit transfer code (TCODE), which defines the type of message; 56 TCODES (0 to 55) indicate that the message is a public, Nexus-defined standard. Seven TCODES (values 56 to 62) indicate that the message is a vendor-defined message. One TCODE (value 63) indicates that the message is a vendor-defined message, and a vendor-designated second-level code identifies the message. Depending on the TCODE, the messages may vary in length. You use the JTAG pins to access standardized development registers and for read/write access to internal memory-mapped peripherals during runtime.
If you use the JTAG protocol, you can perform only static debugging, such as starting or stopping the µP, modifying registers, or single-stepping. Thus, Nexus lets you access memory while the processor is running. Using this feature, you can perform real-time debugging without stopping the µP. But access to real-time information does not come cheap. Nexus has defined a scalable set of pins, the auxiliary port, which uses three to 16 data pins, depending on how the data should appear to assist debugging aids, such as in-circuit emulators and logic analyzers.
Nexus divides debugging-development needs into classes of compliance. Starting from Class 1, each class has an increasing level of complexity, and each higher class covers the functions of the lower classes. Class 1 covers basic static debugging, such as runtime-control functions using the JTAG interface. Class 2 supports ownership and programming trace and also allows you to multiplex auxiliary debug ports with I/O-port pins. Class 3 includes data-write-trace and memory read/write without halting µP execution. Class 4 adds memory substitution, which lets you fetch or read data over the auxiliary port. You can also trigger tracing using a watchpoint. A watchpoint is similar to a breakpoint except that a watchpoint does not cause the µP to halt. You use a watchpoint message via the auxiliary port to signal that a condition has occurred.
You must make trade-offs between the number of pins your design needs and the die size necessary to implement the class 1 to 4 Nexus features. You must also consider cost.
"If you reduce the number of pins, you reduce the bandwidth," says Hugh O'Keeffe, R&D manager at tool maker Ashling. "You can get the same type of information, but bandwidth suffers." Some semiconductor vendors are overcoming this problem by putting only Class 1-compliant features on their production chips and versions of the chip with Class 1 or Class 2 ports on them, depending on the application," says O'Keeffe.
Nonintrusive features
The program-trace feature defines a standard protocol for program-trace visibility that is processor-independent. Using a branch-trace mechanism, the program-trace feature collects the information to trace program execution. For example, the branch-trace mechanism takes into account how many sequential instructions the processor has executed since the last taken branch or exception. Then, the debugging tool can interpolate the program trace for sequential instructions from a local image of program-memory contents. In this way, the debugging tool can reconstruct the full program flow (Figure 2).
You can use the data-trace feature to track real-time data accesses to device-specific internal peripheral and memory locations by specifying a start and stop address with read or write access. Data-trace messaging is a powerful way to find data errors in high-end communication applications.
For debugging applications under RTOS control, Nexus provides an ownership-trace feature, which allows a real-time operating system to identify the currently executing process or task to the debugging tool. By writing to a predefined Nexus standard register whenever it switches tasks, the RTOS forces the auxiliary port to issue an ownership message.
Nexus also addresses debugging of multiprocessor-based applications. The Nexus standard allows embedded-processor implementations that comprise multiple clients to use a single auxiliary port, depending on the application's data-transfer-bandwidth requirements.
To speed interconnection of development tools with target hardware, the Nexus standard defines the 20-pin Connector A, 30-pin Connector B, and 80-pin Connector C standards. The connectors support different levels of debugging signals. For example, you can use Connector B in IEEE 1149.1-only mode, in an auxiliary port with four data-output pins and two data-input pins, or in a combination IEEE 1149.1/auxiliary-output configuration with two data-output pins.
You can use the combined-configuration connector in applications that require additional bandwidth of the auxiliary port while relying on JTAG. Nexus recommends this connector option while you need to perform static debugging using JTAG with program trace on an auxiliary port during runtime. The standardization of connectors minimizes end users' device-connection problems and moves the processor from the emulator to the debugging target.
If Nexus succeeds, Nexus compliance could be one of the major device-selection criteria for application developers. "Some applications are going to require a real-time debug interface," says Ron Stence, system-engineering manager at Motorola. "Applications such as disk drives, cellular phones, and engine calibration require a good, real-time interface. We believe Nexus 5001 interface can address that need." Stence believes that, once the semiconductor vendors put Nexus support into their devices, many tool vendors will adopt it and that tools from one vendor will then work with architectures from other vendors."
Because so much data is available on the Nexus debugging interface, you might think that logic analyzers would play a smaller role in debugging high-end embedded systems because you can analyze more data using software debuggers than you can using with hardware tools, such as logic analyzers, for example. But this assumption may be incorrect.
"The Nexus port will have to run faster and faster and possibly wider to keep up the high-end devices," says Paul K Andersen, product marketing manager for logic analyzers at Tektronix. "Also, high-end applications will have large amounts of internal memory, and applications will be written in high-level languages, such as C++." He believes that this situation will create the need for applications to collect large amounts of trace information from a fast, wide debugging port—a task that logic analyzers excel at.
oth O'Keeffe and Stence believe that, to find wide adoption, Nexus needs to consider a few more issues. O'Keeffe cites code-coverage analysis as one such issue, and Stence points out the need to scale down to cover lower end applications using 8-bit µPs.
"The Nexus concept is a good idea, and it can help make it easier to provide support for devices using it," says Stence. "However, we have some concerns about the consistency of its implementation between vendors." And Andersen sees a potential problem in a fast core that could overrun the output buffer before transferring out the data.
In the near future, even DSPs could benefit from the Nexus standard, according to Stence. DSPs are a primary target for the Nexus interface because they are real-time devices for such applications as hard-disk drives and video processing. Dedicating 40,000 gates to debugging may be overkill, because they focus on one application, but with future smaller geometries, Nexus may be feasible for DSPs.
Author info
|
You can reach Technical Editor NS Manju Nath at +852-2965-1555, fax +852-2976-0706, nsmanjunath@cahners.com.hk.
REFERENCE
1.The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface, Dec 15, 1999.
2. Gonzales, David R, "MCore architecture implements real-time debug port based on Nexus Consortium specification," Motorola MCore Technology Center, Austin, TX.
For more information...
For information on subjects discussed in this article, use EDN's InfoAccess service . When you contact any of the following manufacturers directly, please let them know you read about their products in EDN.
Agilent Technologies
www.agilent.com
Enter No. 313
AMD
1-408-732-2400
www.amd.com
Enter No. 314
Ashling Microsystems
+353 61-334466
www.ashling.com
Enter No. 315
ETAS
1-734-997-9393
www.etas.de
Enter No. 316
Hewlett-Packard
1-800-452-4844
www.hp.com
Enter No. 317
Hitachi
www.hitachi.com/semiconductor
Enter No. 318
Infineon Technologies
1-408-777-4500
www.infineon.com
Enter No. 319
Motorola Semiconductors
www.motorola.com
Enter No. 320
Nexus 5001 Forum
IEEE-ISTO
1-732-981-3434
www.nexus-standard.org
Enter No. 321
Tektronix
www.tek.com
Enter No. 322
