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.

System Trace Protocol Specification

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. It defines all message types and message sequences used by STPv2. In addition, it presents a detailed model of the STPv2 protocol along with pseudo-code examples showing how STPv2 is decoded. Finally, this document provides informative examples of typical STPv2 use-cases and system configurations. 

This specification does not provide definitions of high-level protocols that use STPv2 as a transport, nor does it provide definitions of the interconnects used to transport STPv2. The configuration and control interfaces for modules that implement STPv2 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. Figure 1 shows a typical debug architecture including System Trace.

 

Open System Trace (OST) Base Protocol Specification

Introduction 

This specification defines the MIPI Alliance Open System Trace Base Protocol (OST BP) for transporting software traces and debugging information, as well as related control information, between a target system (TS), typically a cell phone, mobile terminal or similar small device running embedded software, and a debug and test system (DTS), typically a computer running one or more debug and test applications (debuggers). 

Scope 

The OST Base Protocol forms the lowest layer of the OST Protocol Suite. It is intended to be used as a layer on top of underlying physical byte transport mechanisms such as the MIPI Alliance System Trace Protocol (STP) or USB, although it could also be used on top of more complex protocol suites such as the MIPI Alliance Unified Protocol (UniPro) or TCP/IP. Note that for some underlying layers, including STP, specific standard rules must be followed. 

In turn the OST Base Protocol serves as the underlying layer for higher layer protocols including open source protocols such as the Eclipse TCF protocol, the OST Trace Data Protocol or even existing legacy and proprietary protocols. See Figure 1. 

Purpose

The purpose of the OST Base Protocol is to provide a common language for exchanging information between a DTS and TS. The OST BP abstracts the underlying layers from the sending and receiving applications, thus removing dependencies on the connection media and platform implementation, simplifying test, and test environment, development and thus lowering program costs.

 

Parallel Trace Interface Specification

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 (see Section 1.3.3).
  • 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 and illustrated in Figure 1.

  • One or more HW modules capture the system transactions with the required data. See the Trace Collect block in Figure 1.
  • 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). See the Trace Format block in Figure 1.

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. See the Trace Export block in Figure 1.

  • The DTC captures the data.
  • The data is decoded and analyzed using the DTS.

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. Figure 2 shows how the PTI implementation is dependent upon system configuration.

Figure 2 - 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 clocksignals 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 modulescommunicate using implementation specific protocols that are beyond the scope of this specification.

 

Trace Wrapper Protocol Specification

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 internal buffer, or for transport via a shared trace 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. Figure 1 shows a typical debug architecture including Instrumentation Interconnect combining trace from multiple sources sent to an internal Trace Buffer or to an external Debug and Test System via an Export Interface.

 

Debug Work Group Release New Document 

MIPI Alliance is pleased to announce the availability of Recommendations for Debug and Trace Connectors. This document provides a recommendation for board level mating connectors that supports new debug communication interfaces and protocols (like IEEE 1149.7) while maintaining a backward compatibility with existing legacy technology. This document also provides recommendations for board level mating connectors that support trace via high-speed parallel interface. Download the document here: http://www.mipi.org/tutorial/recommendation-debug-and-trace-connectors