Debug Specifications*

Debug Specifications

The Debug group develops specifications which benefit numerous elements within a mobile device including application processors, modems, display controllers, touchscreen controllers, power management CPU, and charging controllers. These specifications enable the capability for debugging and profiling devices.

Specifications are available to MIPI members only. For more information on joining MIPI, please go to Join MIPI.

Specification for System Trace Protocol

Introduction

Real-time trace has become an indispensable tool for debugging and optimizing embedded systems. This trace can come from a variety of sources, including trace components monitoring processor instruction and data flow, instrumentation in the software running on a processor, and trace components monitoring activities outside the processor. 

Each trace source has its own protocol, and these protocols share a number of common required features. The System Trace Protocol (STP) is a base protocol which provides these common features. The advantages of this shared approach include reuse, which reduces the time and cost of designing new protocols, as well as IP and tools supporting them, commonality of features, which enables greater interoperability, for example, by providing time correlation between multiple trace streams, and a robust base protocol, which ensures common protocol design mistakes are avoided. 

Scope

This specification defines the behavior of, and the elements necessary to implement, the System Trace Protocol Version 2.x It defines all message types and message sequences used by STP. In addition, it presents a detailed model of the STP protocol along with pseudo-code examples showing how STP is decoded. Finally, this document provides informative examples of typical STP use-cases and system configurations. 

This specification does not provide definitions of high-level protocols that use STP as a transport, nor does it provide definitions of the interconnects used to transport STP. The configuration and control interfaces for modules that implement STP are also out of scope for this specification.

Purpose

As the complexity of silicon systems increases, system and software developers have an increasing need for visibility into the behavior of the software and hardware modules of these systems. A robust debug system is necessary to address this need. STP is one of the building blocks of such a system, and provides a generic base protocol that can be utilized by application-specific trace functions. The figure below shows a typical debug architecture including System Trace.

STP in the MIPI Debug Architecture

 

Specification for Parallel Trace Interface 

Introduction

It has become an accepted axiom that as the complexity of an embedded system increases, the need for system designers and developers to obtain visibility into the behavior of the system increases proportionally. One of the most common methods for providing this visibility is to provide a streaming interface on an embedded System on a Chip. This interface can be used to export data about system functionality and behavior to a host system for analysis and display. Since the data exported on this interface often allows developers to reconstruct (or “trace”) some portion of system activity, these types of interface have commonly been referred to as Trace Interfaces or Trace Ports.

Examples of trace data include:

  • The instruction execution sequence for one or more embedded processors. This is commonly referred to as Program Counter (PC) Trace.
  • Data bus transactions made by an embedded processor core. This is commonly referred to as Data Trace.
  • Snapshots of transactions on the system interconnect(s). This is commonly referred to as System Trace.
  • Streaming output from instrumented application code. This is commonly referred to as Instrumentation Trace

The bandwidth requirements for the common trace functions listed above often compel system designers to implement the trace interface as a parallel interface with multiple data signals and a clock. For purposes of this document, the trace interface will subsequently be referred to as the Parallel Trace Interface or PTI.

Scope

The specification defines the behaviour of the MIPI Parallel Trace Interface.

Specification Is:

  • A specification of PTI signal names and functions
  • A specification for PTI timing constraints
  • A specification for PTI electrical constraints

Specification Is Not:

  • The functional definition of any module that implements a PTI
  • The definition of any trace data protocol that is transmitted over a PTI
  • The definition of the physical mating connection used to connect the DTC to the PTI on a Target System.
  • The definition of any other debug interface
  • The definition of debug pin management within a Target System
  • The definitions of any trace interleaving modules or the interleaving protocols implemented by these modules

Purpose

A typical embedded system may have one or more HW modules that produce trace data. The typical flow is outlined below.

On the Target System:

  • Trace Collect: One or more HW modules capture the system transactions with the required data.
  • Trace Format: One or more HW modules encode or compress the data into an implementation specific encoding(s). These encoding(s) are called the Trace Data Protocols (TDPs).
  • Trace Export: One or more HW modules export the encoded data to the DTC using device pins. The interface used to transfer this data is the Parallel Trace Interface or PTI. 

The Debug & Test System captures the data, decodes them and provides various means to analyze the collected data. 

Example for a PTI

It should be noted that only HW modules directly responsible for producing the data and clock of a PTI are required to implement a PTI. The figure below shows how the PTI implementation is dependent upon system configuration.

PTI Layers within a System

The scenario for Trace Module 0 is reasonably straight forward. The module itself is directly connected to a dedicated PTI on the device boundary and the module is responsible for implementing the PTI.

The scenario for Trace Modules 1-3 is slightly more complex. Here multiple modules export trace through a device level pin manager or mux. This management logic is only responsible for controlling which pins on the device PTI are assigned to the device internal trace clients. It does not produce the data and clock signals for the PTI but only routes them from the various trace modules. Thus the individual trace modules are required to implement the PTI. Since the pin manager routes the internal PTI signals to the device boundary, there is also a PTI at the device pins.

The scenario for Trace Modules 4-6 shows a system where multiple trace modules provide data over a proprietary trace interconnect. This system allows data to be combined or interleaved in some fashion before export. The interleaving and export module implements the PTI and the individual trace modules communicate using implementation specific protocols that are beyond the scope of this specification.

Specification for Trace Wrapper Protocol

Introduction

Real-time trace has become an indispensable tool for debugging and optimizing embedded systems. This trace can come from a variety of sources, including trace components monitoring processor instruction and data flow, instrumentation in the software running on a processor, and trace components monitoring activities outside the processor.

The trace data is typically transported to an external Debug and Test System for analysis. The Trace Wrapper Protocol (TWP) facilitates combining several streams of trace data for storage in an on-chip Debug Buffer, or for transport via a shared Debug export interface, which makes more efficient use of system resources. 

Scope

This specification describes the data format used by the Trace Wrapper Protocol, and how it can be used to represent multiple, pre-interleaved trace streams each using their own trace protocols. It also defines the features of the three layers of TWP, and offers recommendations for when these layers should be utilized. It does not provide definitions of trace protocols that may be wrapped by TWP, nor does it provide definitions of the interconnect or interfaces used to transport TWP. The configuration and control interfaces for modules that implement TWP are also out of scope for this specification. 

Purpose 

As the complexity of silicon systems increases, system and software developers have an increasing need for visibility into the behavior of the software and hardware modules of these systems. A common technique for providing this visibility is adding trace sources associated with the software and hardware modules. TWP is one of the building blocks of a debug system, and provides a wrapping protocol to combine trace data from multiple trace sources. The figure below shows a typical debug architecture including Instrumentation Interconnect combining trace from multiple sources sent to an internal Debug Buffer or to an external Debug and Test System via an Debug Export Interface.

TWP in the MIPI Debug Architecture

 

Specification for Narrow Interface for Debug and Test (NIDnT)

Product development in the mobile space is done using development boards. Development boards provide dedicated and readily-accessible interfaces for connecting the debug tools. These interfaces are not available at the product’s final form factor. This hampers the identification of bugs and performance optimization in the end product.

The Specification for Narrow Interface for Debug and Test (NIDnT) standardized a way to utilize functional interfaces (here Micro SD interface) for debug. It describes how to implement a dual use functional interface by multiplexing the debug signals with the normal function signals within the SoC in a manner that is similar to a switch connecting either the normal function or the debug function.

Target System with NIDnT Capability 

A Debug & Test System (DTS) connected to the Target System (TS) can use the following ways to switch the functional interface to debug function:

  • Negotiating by using the functional protocol
  • Stimulating the pin interface in a standardized manner
  • Switching by the mobile terminal´s firmware (out of the specification´s scope)

The six pin SD card interface allows the following debug configurations:

  • cJTAG (IEEE 1149.7) or ARM´s SWD and optional up to 4 trace data pins
  • UART plus 4 trace data pins and a trace clock
  • 4 trace data pins and trace clock

Recommendation for Debug and Trace Connectors

 

Board developers and debug tools vendors benefit from standard debug connectors and standard pin mappings. Recommended are 10-/20-/34-pin board-level connectors (1.27 mm 0.050"). Seven different pin mappings are specified that address a wide variety of debug use scenarios. They include:

  • Standard JTAG (IEEE 1149.1)
  • ARM-specific standard SWD (Serial Wire Debug)
  • cJTAG (IEEE 1149.7)
  • 4-bit parallel trace interface (mainly used for System Traces)

Many embedded designs in the mobile space use high-speed parallel trace ports (up to 600 Mbit/s/pin). MIPI recommends a 60-pin Samtec QSH/QTH connector named MIPI60. It allows JTAG/cJTAG/SWD for run control, up to 40 trace data signals and up to 4 trace clocks. To minimize complexity, the recommendation defines four standard configurations with one, two, three or four trace channels of varying width.