MIPI Debug Architecture


MIPI Alliance Debug Architecture provides a standardized infrastructure for debugging deeply embedded systems in the mobile and mobile-influenced space. The MIPI Alliance MIPI Debug Working Group has released a portfolio of specifications; their objective is to provide standard debug protocols and standard interfaces from a system on a chip to the debug tool. The whitepaper Architecture Overview for Debug summarizes all the efforts. In recent years, the group focused on specifying protocols that improve the visibility of the internal operations of deeply embedded systems, standardizing debug solutions via the functional interfaces of form factor devices, and specifying the use of I3C as debugging bus.

The term "debug"

The term "debug" encompasses the various methods used to detect, triage, trace, and potentially eliminate mistakes, or bugs, in hardware and software. Debug includes control/configure methods, stop/step mode debugging, and various forms of tracing.

Control/configure methods

Debug can be used to control and configure components, including embedded systems, of a given target system. Standard functions include setting up hardware breakpoints, preparing and configuring the trace system, and examining system states.

Stop/step mode debugging

In stop/step mode debugging, the core/microcontroller is stopped through the use of breakpoints and then "single-stepped" through the code by executing instructions one at a time. If the other cores/microcontrollers of the SoC have finished synchronously, the overall state of the system can be examined. Stop/step mode debugging includes control/configure techniques, run control of a core/microcontroller, start/stop synchronization with other cores, memory and register access, and additional debug features such as performance counter and run-time memory access.

Tracing

Traces allow an in-depth analysis of the behavior and the timing characteristics of an embedded system. The following traces are typical:
Tracing is the tool of choice to monitor and analyze what is going on in a complex SoC. There are several well established non-MIPI core-trace and bus-trace standards for the embedded market. Thus, there was no need for the MIPI Debug Working Group to specify new ones. But no standard existed for a "system trace" when the Debug Working Group published its first version of the MIPI System Trace Protocol in 2006.

''MIPI System Software Trace'' (MIPI SyS-T)

The generation of system trace data from the software is typically done by inserting additional function calls, which produce diagnostic information valuable for the debug process. This debug technique is called instrumentation. Examples are: printf-style string generating functions, value information, assertions, etc. The purpose of MIPI System Software Trace is to define a reusable, general-purpose data protocol and instrumentation API for debugging. The specification defines message formats that allow a trace-analysis tool to decode the debug messages, either into human-readable text or to signals optimized for automated analysis.
Since verbose textual messages stress bandwidth limits for debugging, so-called "catalog messages" are provided. Catalog messages are compact binary messages that replace strings with numeric values. The translation from the numeric value to a message string is done by the trace analysis tool, with the help of collateral XML information. This information is provided during the software-build process using an XML schema that is part of the specification as well.
The SyS-T data protocol is designed to work efficiently on top of lower-level transport links such as those defined by the MIPI System Trace Protocol. SyS-T protocol features such as timestamping or data-integrity checksums can be disabled if the transport link already provides such capabilities. The use of other transport links—such as UART, USB, or TCP/IP—is also possible.
The MIPI Debug Working Group will provide an open-source reference implementation for the SyS-T instrumentation API, a SyS-T message pretty printer, and a tool to generate the XML collateral data as soon as the Specification for System Software Trace is approved.

''MIPI System Trace Protocol'' (MIPI STP)

The MIPI System Trace Protocol specifies a generic protocol that allows the merging of trace streams originated from anywhere in the SoC to a trace stream of 4-bit frames. It was intentionally designed to merge system trace information. The MIPI System Trace Protocol uses a channel/master topology that allows the trace receiving analysis tool to collate the individual trace streams for analysis and display. The protocol additionally provides the following features: stream synchronization and alignment, trigger markers, global timestamping, and multiple stream time synchronization.
The stream of STP packets produced by the System Trace Module can be directly saved to trace RAM, directly exported off-chip, or can be routed to a "trace wrapper protocol" module to merge with further trace streams. ARM's CoreSight System Trace Macrocell, which is compliant with MIPI STP, is today an integral part of most multi-core chips used in the mobile space.
The last MIPI board-adopted version of Specification for System Trace Protocol is version 2.2 .

''MIPI Trace Wrapper Protocol'' (MIPI TWP)

The MIPI Trace Wrapper Protocol enables multiple trace streams to be merged into a single trace stream. A unique ID is assigned to each trace stream by a wrapping protocol. The detection of byte/word boundaries is possible even if the data is transmitted as a stream of bits. Inert packets are used if a continuous export of trace data is required. MIPI Trace Wrapper Protocol is based on ARM's Trace Formatter Protocol specified for ARM CoreSight.
The last MIPI board-adopted version of Specification for Trace Wrapper Protocol is version 1.1 .

From dedicated to functional interfaces

Dedicated debug interfaces

In the early stages of product development, it is common to use development boards with dedicated and readily accessible debug interfaces for connecting the debug tools. SoCs employed in the mobile market rely on two debug technologies: stop-mode debugging via a scan chain and stop-mode debugging via memory-mapped debug registers.
The following non-MIPI debug standards are well established in the embedded market: IEEE 1149.1 and ARM Serial Wire Debug, both using single-ended pins. Thus, there was no need for the MIPI Debug Working Group to specify a stop-mode debug protocol or to specify a debug interface.
Trace data generated and merged to a trace stream within the SoC can be streamed, via a dedicated unidirectional trace interface, off-chip to a trace analysis tool. The MIPI Debug Architecture provides specifications for both parallel and serial trace ports.
The MIPI Parallel Trace Interface specifies how to pass the trace data to multiple data pins and a clock pin. The specification includes signal names and functions, timing, and electrical constraints. The last MIPI board-adopted version of Specification for Parallel Trace Interface is version 2.0.
The MIPI High-Speed Trace Interface specifies how to stream trace data over the physical layer of standard interfaces, such as PCI Express, DisplayPort, HDMI, or USB. The current version of the specification allows for one to six lanes. The specification includes:
The HTI is a subset of the High Speed Serial Trace Port specification defined by ARM. The last MIPI board-adopted version of Specification for High-speed Trace Interface is version 1.0.
Board developers and debug tool vendors benefit from standard debug connectors and standard pin mappings. The MIPI Recommendation for Debug and Trace Connectors recommends 10-/20-/34-pin board-level connectors. Seven different pin mappings that address a wide variety of debug scenarios have been specified. They include standard JTAG, cJTAG and 4-bit parallel trace interfaces, supplemented by the ARM-specific Serial Wire Debug standard. MIPI10/20/34 debug connectors became the standard for ARM-based embedded designs.
Many embedded designs in the mobile space use high-speed parallel trace ports. MIPI recommends a 60-pin Samtec QSH/QTH connector named MIPI60, which allows JTAG/cJTAG 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.
The last MIPI board-adopted version of MIPI Alliance Recommendation for Debug and Trace Connectors is version 1.1.

PHY and pin overlaid interfaces

Readily-accessible debug interfaces are not available in the product's final form factor. This hampers the identification of bugs and performance optimization in the end product. Since the debug logic is still present in the end product, an alternative access path is needed. An effective way is to equip a mobile terminal's standard interface with a multiplexer that allows for accessing the debug logic. The switching between the interface's essential function and the debug function can be initiated by the connected debug tool or by the mobile terminal's software. Standard debug tools can be used under the following conditions:
The MIPI Narrow Interface for Debug and Test covers debugging via the following standard interfaces:
microSD, USB 2.0 Micro-B/-AB receptacle, USB Type-C receptacle, and DisplayPort. The last MIPI board-adopted version of Specification for Narrow Interface for Debug and Test is version 1.2.

Network interfaces

Instead of re-using the pins, debugging can also be done via the protocol stack of a standard interface or network. Here debug traffic co-exists with the traffic of other applications using the same communication link. The MIPI Debug Working Group named this approach GigaBit Debug. Since no debug protocol existed for this approach, the MIPI Debug Working Group specified its SneakPeak debug protocol.
MIPI SneakPeek Protocol moved from a dedicated interface for basic debugging towards a protocol-driven interface:
The MIPI Alliance Specification for SneakPeek Protocol describes the basic concepts, the required infrastructure, the packets, and the data flow. The last MIPI board-adopted version of Specification for SneakPeek Protocol is version 1.0.
The MIPI Gigabit Debug Specification Family is providing details for mapping debug and trace protocols to standard I/Os or networks available in mobile terminals. These details include: endpoint addressing, link initialization and management, data packaging, data-flow management, and error detection and recovery. The last MIPI board-adopted version of Specification for Gigabit Debug for USB is version 1.1. The last MIPI board-adopted version of Specification for Gigabit Debug for Internet Protocol Sockets is version 1.0.

I3C as debug bus

Current debug solutions, such as JTAG and ARM CoreSight, are statically structured, which makes for limited scalability regarding the accessibility of debug components/devices. MIPI Debug for I3C specifies a scalable, 2-pin, single-ended debug solution, which has the advantage of being available for the entire product lifetime. The I3C bus can be used as a debug bus only, or the bus can be shared between debug and its essential function as data acquisition bus for sensors. Debugging via I3C works in principle as follows: