The IEEE-ISTO 5001-2003 feature set is modeled on today's on-chip debug implementations, most of which are processor-specific. Its goal is to create a rich debug feature set while minimizing the required pin-count and die area, and being both processor- and architecture independent. It also supports multi-core and multi-processor designs. Accordingly, it is comparable to the ARM CoreSight debug architecture. Physically, IEEE-ISTO 5001-2003 defines a standard set of connectors for connecting the debug tool to the target or system under test. Logically, data is transferred using a packet-based protocol. This protocol can be JTAG ; or, for high-speed systems, an auxiliary port can be used that supports full duplex, higher bandwidth transfers. Key Nexus functionality involves either JTAG-style request/response interactions, or packets transferred through the debug port, and includes:
Run-time control... With all implementations, debug tools can start and stop the processor, modify registers, and single-step machine instructions.
Memory access... Nexus supports memory access while the processor is running. Such access is required when debugging systems where it is not possible to halt the system under test. Examples include Engine Control, where stopping digital feedback loops can create physically dangerous situations.
Breakpoints... Programs halt when a specified event, a breakpoint, has occurred. The event can be specified as a code execution address, or as a data access to an address with a specified value. Nexus breakpoints can be set at any address, including flash or ROM memory; CPUs may also provide special breakpoint instructions.
Several kinds of event tracing are defined, mostly depending on a high speed auxiliary port to offload the voluminous data without negatively impacting program execution:
* Program trace... Branch tracing compresses program execution data, by emitting messages at branch or exception instructions only. Trace analysis reconstructs the program flow using a local image of code memory contents.
* Data trace... Accesses to memory locations may be tracked, as limited by range and access type.
* Ownership trace... An operating system may write a task identifier to a Nexus register when switching tasks, forcing an ownership trace message to be emitted.
Memory substitution and port replacement... This feature allows memory or port accesses to be emulated over the auxiliary Nexus port.
Data acquisition... Rapid prototyping may require rapid transfer of large amounts of data via the auxiliary port to the debug tools. It uses a more efficient protocol than that used in data trace. It also helps calibration in automotive applications.
A low-level application programming interface is also allowed for, to mask target specifics such as the host connection mechanism and processor specific Nexus register details. This API is produced jointly by the tool and semiconductor vendor.
Compliance classes
IEEE-ISTO 5001-2003 is a scalable standard; there are currently four classes of compliance to the standard, ranging from the basic Class 1 up to Class 4.
Class 1 supports run-time control using the JTAG interface. Communications are half duplex only and bandwidth is limited. Trace is not supported.
Class 2 adds ownership trace and program trace and allows the auxiliary debugging port to be shared with "slow" I/O port pins. Ownership trace allows current task or current process trace for systems based on real-time kernels or operating-systems.
Class 3 adds data write trace and memory read/write on-the-fly without halting execution. Data read/write tracing, sharing of the auxiliary port with high speed I/O ports such as the address/data bus, and support for data acquisition may also be optionally part of Class 3 compliance.
Class 4 adds memory substitution and allows tracing to be triggered by a watchpoint. Triggering memory substitution on a watchpoint is an optional feature of Class 4 compliance.
