Nexus (standard)

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Nexus" standard – news · newspapers · books · scholar · JSTOR (June 2010) (Learn how and when to remove this message)

Nexus or IEEE-ISTO 5001-2003 is a standard debugging interface for embedded systems.

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.^{[clarification needed]}
• 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^{[clarification needed]}) and processor specific Nexus register details. This API is produced jointly by the tool and semiconductor vendor.

IEEE-ISTO 5001-2003 is a scalable standard; there are currently four classes of compliance to the standard, ranging from the basic (JTAG only) Class 1 up to Class 4.

• Class 1 supports run-time control (run, stop, memory upload/download when the processor is halted, breakpoints, read or set registers) 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 (visibility of related data parameters stored in internal resources, typically related calibration variables) may also be optionally part of Class 3 compliance.
• Class 4 adds memory substitution (fetching or reading data over the Nexus auxiliary port) and allows tracing to be triggered by a watchpoint. Triggering memory substitution on a watchpoint is an optional feature of Class 4 compliance.

• BDM
• JTAG

• IEEE-ISTO 5001™-1999,The Nexus 5001 Forum™ Standard - providing the Gateway to the Embedded Systems of the Future
• IEEE-ISTO 5001-2003, The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface

• NEXUS 5001 Forum
• Nexus 5001 Forum Global Embedded Processor Debug Interface Standard, by William Wong
• Multi-core analysis made easy with the Nexus 5001 debug spec, by Dr. Neal Stollon
• The NEXUS Debug Standard: Gateway to the Embedded Systems of the Future, by Ashling Microsystems, Inc.