Nexus (standard) - Features

Features

The IEEE-ISTO 5001-2003 (Nexus) 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 (IEEE 1149.1); 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 (read or write) 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 (start and stop address) and access type (read or write).
  • Ownership trace ... An operating system (OS, possibly an RTOS) 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 (API) is also allowed for, to mask target specifics such as the host connection mechanism (such as an emulator or Calibration-instrument) and processor specific Nexus register details. This API is produced jointly by the tool and semiconductor vendor.