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.
|NEXUS NXAPI.H DEFINITIONS|
|nx_Open||open a target connection|
|nx_Close||close a target connection|
|nx_WriteMem||write target memory|
|nx_ReadMem||read target memory|
|nx_SetEvent||set an event|
|nx_ClearEvent||clear an event|
|nx_Control()||Read/write user registers in debug mode|
|nx_WriteMem()||Write user memory in debug mode|
|nx_ReadMem()||Read user memory in debug mode|
|nx_Control()||Enter a debug mode from reset|
|nx_Control()||Enter a debug mode from user mode|
|nx_Control()||Exit a debug mode to user mode|
|nx_SetEvent()||Single step instruction in user mode and re-enter debug mode|
|nx_SetEvent()||Stop program execution on instruction/data breakpoint and enter debug mode (minimum 2 breakpoints)|
|nx_SetEvent()||Ability to set breakpoint or watchpoint|
|nx_SetEvent()||Ability to send out an event occurrence when watchpoint matches|
|nx_GetEvent()||Monitor process ownership while processor runs in real time|
|nx_GetEvent()||Monitor program flow while processor runs in real time (logical address)|
|nx_GetEvent()||Monitor data writes while processor runs in real time|
|nx_WriteMem()||Write memory locations while program runs in real time|
|nx_ReadMem()||Read memory locations while program runs in real time|
|nx_GetEvent()||Program execution (instruction/data) from Nexus port for reset or exceptions|
|nx_SetEvent()||Ability to start ownership, program, or data trace upon watchpoint occurrence|
|nx_SetEvent()||Ability to start memory substitution upon watchpoint occurrence or upon program access of device-specific address|
|nx_GetEvent()||Monitor data reads while processor runs in real time|
|nx_Control()||LSIO port replacement and HSIO port sharing|
|nx_SetEvent()||Transmit data values for acquisition by tool|
Nexus 5001 Class Specifications
The Nexus 5001 Forum's Interface standard allows various levels of conformance. This permits im-plementation of different performance levels and the use of resources in a way desired by the hardware designer. The same API is supported regardless of the underlying implementation.
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.
|STATIC DEVELOPMENT FEATURES|
|DEVELOPMENT FEATURE||CLASS 1||CLASS 2||CLASS 3||CLASS 4||NEXUS FEATURE|
|Read/write user registers in debug mode||V||V||V||V||Read/Write Access|
|Read/write user memory in debug mode||A||A||A||A||Read/Write Access|
|Enter a debug mode from reset||A||A||A||A||Development Control and Status|
|Enter a debug mode from user mode||A||A||A||A||Development Control and Status|
|Exit a debug mode to user mode||A||A||A||A||Development Control and Status|
|Single-step instruction in user mode and re-enter debug mode||A||A||A||A||Development Control and Status|
|Stop-program execution on instruction/data breakpoint and enter debug mode (minimum 2 breakpoints)||A||A||A||A||Breakpoints/Watchpoints|
|DYNAMIC DEVELOPMENT FEATURES|
|DEVELOPMENT FEATURE||CLASS 1||CLASS 2||CLASS 3||CLASS 4||NEXUS FEATURE|
|Ability to set breakpoint or watchpoint||A||A||A||A||Breakpoints/Watchpoints|
|Device Identification||A||A and P||A and P||A and P||Device ID Message|
|Ability to send out an event occurrence when watchpoint matches||P||P||P||P||Watchpoint Message|
|Monitor process ownership while processor runs in real time||—||P||P||P||Ownership Trace|
|Monitor program flow while processor runs in real time (logical address)||—||P||P||P||Program Trace|
|Monitor data writes while processor runs in real time||—||—||P||P||Data Trace (Writes only)|
|Read/write memory locations while program runs in real time||—||—||A and P||A and P||Read/Write Access|
|Program execution (instruction/data) from Nexus port for reset or exceptions||—||—||—||P||Memory Substitution|
|Ability to start ownership, program, or data trace upon watchpoint occurrence||—||—||—||A||Development Control and Status|
|Ability to start memory substitution upon watchpoint occurrence or upon program access of device-specific address||—||—||—||O||Development Control and Status|
|Monitor data reads while processor runs in real-time||—||—||O||O||Data Trace (Reads and Writes)|
|LSIO port replacement and HSIO port sharing||—||O||O||O||Port Replacement/Sharing|
|Transmit data values for acquisition by tool||—||—||O||O||Data Acquisition|
|V: a required vendor-defined development feature implemented in the Nexus API|
|A: a required development feature that must be implemented via the Nexus API|
|P: a required development feature that must be implemented via the Nexus development port as a Public Message or with a Nexus port pin (as appropriate)|
|O: an optional development feature as defined by the Nexus standard|