Nexus 5001 Forum Global Embedded Processor Debug Interface Standard

Few debugging standards exist, which makes the Nexus 5001 Forum's Global Embedded Processor Debug Interface standard stand out. Based on the IEEE-1149.1 JTAG bus, the Nexus 5001 standard provides a way to integrate general debugging tools with platform-dependent debugging hardware, versus the use of custom debugging tools and associated hardware.

Initially targeted at automotive control system-on-a-chip (SoC) applications, the IEEE Industry Standards and Technology Organization (ISTO) Nexus 5001 Forum standard is suitable to use in any processing environment. It's recognized by the IEEE Vehicular Technology Society.

The IEEE 1149.1 is primarily a serial bus employed for monitoring and setting register contents within a system under test (SUT). The Nexus 5001 Debug Interface Standard adds an AUX port to in-crease throughput to ac-commodate the movement of debugging data between the SUT and the debugging application.

The standard addresses both the hardware interface and the software application programming interface (API). The Nexus 5001 API consists of only half a dozen function definitions.

The standard nxapi.h file contains C function definitions al-though there is no restriction on the language used to implement either the underlying Emulator Hardware Abstraction Layer (HAL) that drives the Nexus 5001 bus interface, or the debug application that communicates with the Tool Abstraction Layer (TAL).

The standard does not dictate how the hardware or software is partitioned, so an implementation may consist of various hardware components. Although the standard does not specify a multiplexing protocol, it is possible to implement the Nexus API to handle multiple processors either on the same chip or spread across multiple boards. Multiplexing in this case can be handled in a fashion similar to multiplexing JTAG-enabled devices.

One of the first applications of the standard was in a design from Motorola Semiconductor, in the company's MMC 2080 32-bit microRISC processor. This product is based on the Motorola M*Core M431RISC processor and a Motorola 56000 DSP core.

See associated figure.

The Class-1 level provides a minimal implementation. This still supports breakpoints and access to memory and registers while minimizing the number of pins in the AUX port. The tradeoff is system performance be-cause it will take a longer time to read or write data. Class-1 implementations are very useful for cases where pin counts are critical, like in handheld applications or other portable environments.

Class 4 is at the other end of the spectrum, where there's a full complement of features. The AUX port maxes out at 16 bits, but it can handle information from a 32- or 64-bit processor.

The size of the AUX port doesn't affect the message-passing protocol controlled by the IEEE-1149.1 port. The interface doesn't impose performance requirements. But, an implementation should have the upload and download speeds specified and an indication of whether the AUX port will operate in a full- or half-duplex mode. Class 1 operates in a half-duplex mode while Classes 2, 3, and 4 operate in full duplex. Also, Class 1 doesn't need an AUX port because it simply uses the IEEE-1149.1 port.

AUX port messages start with a 6-bit TCODE that uniquely defines the message type. There are 56 values reserved or defined by the standard. For Vendor Defined Messages, 8 TCODEs are allocated. The number of messages supported by an implementation is based on the class that, in turn, supports various features, including breakpoints, watchpoints, and even tracing capabilities found in Classes 3 and 4.

The standard defines a number of different mechanical interfaces for board-level connections. This enables debug interface hardware that supports the Nexus 5001 standard to plug into a Nexus 5001-compatible DUT. The complete standard can be found on the Forum's Web site.