Architecture Overview
for Debug
White Paper
Version 1.3
19 March 2021
MIPI Board Approved for Public Distribution 21 April 2021

This is an informative document, not a MIPI Specification.
Various rights and obligations that apply solely to MIPI Specifications (as defined in the MIPI
Membership Agreement and MIPI Bylaws) including, but not limited to, patent license rights andobligations, do not apply to this document.
The material contained herein is not a license, either expressly or impliedly, to any IPR owned orcontrolled by any of the authors or developers of this material or MIPI. All materials contained herein areprotected by copyright laws, and may not be reproduced, republished, distributed, transmitted, displayed,broadcast or otherwise exploited in any manner without the express prior written permission of MIPI
Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related trademarks, trade names, andother intellectual property are the exclusive property of MIPI Alliance and cannot be used without its
express prior written permission.
This document is subject to further editorial and technical development.
USB Type-CTM is a trademark of the USB Implementers Forum.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Architecture Overview for Debug

Version 1.3
19-Mar-2021

NOTICE OF DISCLAIMER
The material contained herein is provided on an “AS IS” basis. To the maximum extent permitted byapplicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developersof this material and MIPI Alliance Inc. (“MIPI”) hereby disclaim all other warranties and conditions, either
express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties orconditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses,
of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO
WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION,
CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS
MATERIAL.
IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR MIPI BE LIABLE
TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES,LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL,
DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT,WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER
AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD
ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
The material contained herein is not a license, either expressly or impliedly, to any IPR owned or controlled
by any of the authors or developers of this material or MIPI. Any license to use this material is granted
separately from this document. This material is protected by copyright laws, and may not be reproduced,
republished, distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without theexpress prior written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all
related trademarks, service marks, tradenames, and other intellectual property are the exclusive property of
MIPI Alliance Inc. and cannot be used without its express prior written permission. The use or
implementation of this material may involve or require the use of intellectual property rights (“IPR”)
including (but not limited to) patents, patent applications, or copyrights owned by one or more parties,
whether or not members of MIPI. MIPI does not make any search or investigation for IPR, nor does MIPI
require or request the disclosure of any IPR or claims of IPR as respects the contents of this material orotherwise.
Without limiting the generality of the disclaimers stated above, users of this material are further notified
that MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the contents of thismaterial; (b) does not monitor or enforce compliance with the contents of this material; and (c) does notcertify, test, or in any manner investigate products or services or any claims of compliance with MIPI
specifications or related material.
Questions pertaining to this material, or the terms or conditions of its provision, should be addressed to:
MIPI Alliance, Inc.
c/o IEEE-ISTO
445 Hoes Lane, Piscataway New Jersey 08854, United States
Attn: Managing Directorii

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

Contents

Figures .................................................................................................................................v
Tables................................................................................................................................ vii
Release History ............................................................................................................... viii
1 Overview ......................................................................................................................1
1.1

2

3
4
5

Scope ............................................................................................................................... 1

Terminology .................................................................................................................2

2.1
2.2
2.3
2.4

Definitions....................................................................................................................... 2
Abbreviations ................................................................................................................. 5
Acronyms ........................................................................................................................ 5
Use of Inclusive Language............................................................................................. 7

References ....................................................................................................................8
Debug System ............................................................................................................ 11

4.1
4.2

System Framework ...................................................................................................... 11
The MIPI Debug and Test System .............................................................................. 13

Debug Physical Interfaces (DPI) ..............................................................................15

5.1
Parallel Trace Interface (PTI) Specification.............................................................. 15
5.1.1 Trace and Debug Overview ........................................................................................ 15
5.1.2 Relationship to MIPI Debug Architecture .................................................................. 16
5.1.3 Trace Scenarios........................................................................................................... 17
5.1.4 Detailed Specification ................................................................................................ 21
5.2
High-speed Trace Interface (HTI) Specification ....................................................... 22
5.2.1 Overview .................................................................................................................... 22
5.2.2 Relationship to the MIPI Debug Architecture ............................................................ 22
5.2.3 HTI Details ................................................................................................................. 23
5.2.4 Detailed Specification ................................................................................................ 23
5.3
Debug Connector Recommendations ......................................................................... 24
5.3.1 Dedicated Debug Connector Overview ...................................................................... 24
5.3.2 Relationship to the MIPI Debug Architecture ............................................................ 24
5.3.3 Basic Debug Connectors ............................................................................................ 25
5.3.4 High-Speed Parallel Trace Connectors ....................................................................... 25
5.3.5 Detailed Documentation ............................................................................................. 26
5.4
Narrow Interface for Debug and Test (NIDnT) Specification ................................. 27
5.4.1 Overview .................................................................................................................... 27
5.4.2 Relationship to the MIPI Debug Architecture ............................................................ 27
5.4.3 NIDnT Details ............................................................................................................ 28
5.4.4 Debug and Test Capabilities Supported by NIDnT Overlay Modes........................... 29
5.4.5 Functional Interfaces that are NIDnT Candidates ...................................................... 30
5.4.6 Detailed Specification ................................................................................................ 30

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

iii

Architecture Overview for Debug

Version 1.3
19-Mar-2021

6

7

8

iv

Debug Access and Control Subsystem (DACS) ......................................................31

6.1
IEEE 1149.7 Debug and Test Interface Specification ............................................... 31
6.1.1 Relationship to MIPI Debug Architecture .................................................................. 33
6.1.2 Detailed Specification ................................................................................................ 33
6.2
SneakPeek Specification .............................................................................................. 34
6.2.1 Relationship to MIPI Debug Architecture .................................................................. 34
6.2.2 Overview .................................................................................................................... 34
6.2.3 Protocol Styles ............................................................................................................ 37
6.2.4 Detailed Specifications ............................................................................................... 37

Debug Instrumentation and Visibility Subsystem (DIVS) ....................................39

7.1
Instrumentation and Visibility Subsystem Overview ............................................... 39
7.2
System Trace Protocol (STP) Specification ............................................................... 39
7.2.1 Relationship to MIPI Debug Architecture .................................................................. 40
7.2.2 Protocol Overview ...................................................................................................... 40
7.2.3 Detailed Specification ................................................................................................ 42
7.3
Trace Wrapper Protocol (TWP) Specification .......................................................... 43
7.3.1 Overview .................................................................................................................... 43
7.3.2 Relationship to MIPI Debug Architecture .................................................................. 44
7.3.3 TWP Features ............................................................................................................. 44
7.3.4 TWP Description ........................................................................................................ 45
7.3.5 Layers ......................................................................................................................... 45
7.3.6 Detailed Specification ................................................................................................ 45
7.4
Gigabit Trace (GbT) .................................................................................................... 46
7.4.1 Summary..................................................................................................................... 46
7.4.2 Relationship to MIPI Debug Architecture .................................................................. 46
7.4.3 Gigabit Trace System Overview ................................................................................. 47
7.4.4 Requirements Summary ............................................................................................. 48
7.4.5 Detailed Specification ................................................................................................ 48
7.5
STP and TWP in the DIVS .......................................................................................... 49
7.6
System Software Trace (SyS-T) Specification ........................................................... 51
7.6.1 Overview .................................................................................................................... 51
7.6.2 Relationship to MIPI Debug Architecture .................................................................. 51
7.6.3 Usage .......................................................................................................................... 52
7.6.4 SyS-T Instrumentation Library ................................................................................... 52
7.6.5 Detailed Specification ................................................................................................ 53

Debug Network Interfaces (DNI) .............................................................................55

8.1
Gigabit Debug (GbD) Specification............................................................................ 55
8.1.1 Overview .................................................................................................................... 55
8.1.2 Relationship to MIPI Debug Architecture .................................................................. 57
8.1.3 Detailed Specifications ............................................................................................... 57
8.2
Debug for I3C ............................................................................................................... 58
8.2.1 Overview .................................................................................................................... 58
8.2.2 Relationship to MIPI Debug Architecture .................................................................. 59
8.2.3 Target System Implementation Overview .................................................................. 59
8.2.4 Detailed Specification ................................................................................................ 61

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

FiguresFigure 1 MIPI Debug Generic System Framework ........................................................................ 12
Figure 2 MIPI Debug Documentation and the Debug Architecture ............................................... 13
Figure 3 Example MIPI System Overview .................................................................................... 14
Figure 4 PTI in the MIPI Debug Architecture ................................................................................ 16
Figure 5 Example System with PTI................................................................................................ 17
Figure 6 PTI Layers within a System ............................................................................................. 18
Figure 7 Multi-Point PTI with 4-Pin Trace and Four Devices Sharing the Connector .................. 20
Figure 8 Multi-Point PTI with 4-Pin Trace and Two Devices Sharing the Connector ................... 21
Figure 9 HTI in the MIPI Debug Architecture ............................................................................... 22
Figure 10 Connectors in the MIPI Debug Architecture .................................................................. 24
Figure 11 Basic Debug PCB (left) and Cable End Connector (34-pin Samtec FTSH) .................. 25
Figure 12 Recommended Samtec QSH/QTH Connector ............................................................... 25
Figure 13 NIDnT in the MIPI Debug Architecture ........................................................................ 27
Figure 14 Example of System with a Dedicated Debug Interface.................................................. 28
Figure 15 Example of System with NIDnT Capability .................................................................. 29
Figure 16 DTS to TS Connectivity ................................................................................................. 32
Figure 17 IEEE 1149.7 in the MIPI Debug Architecture ............................................................... 33
Figure 18 SneakPeek in the MIPI Debug Architecture .................................................................. 34
Figure 19 Overview of SneakPeek System .................................................................................... 35
Figure 20 SneakPeek Protocol and Network Stacks in DTS and TS ............................................. 36
Figure 21 STP in the MIPI Debug Architecture ............................................................................. 40
Figure 22 Conceptual Hierarchy of STP Major Sources and Channels ......................................... 41
Figure 23 STM in a Target System ................................................................................................. 42
Figure 24 Example STP Packet Sequence ...................................................................................... 42
Figure 25 TWP in the MIPI Debug Architecture............................................................................ 44
Figure 26 Example Use Cases for Layers T1, T2 and T3............................................................... 45
Figure 27 Gigabit Trace and the MIPI Debug Architecture ........................................................... 46
Figure 28 Typical GbT Configuration and Data Flow (TS) ........................................................... 47
Figure 29 Typical GbT Configuration and Data Flow (DTC and DTS) ......................................... 48
Figure 30 Example Trace Architecture ........................................................................................... 50
Figure 31 SyS-T in the MIPI Debug Architecture .......................................................................... 51

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

v

Architecture Overview for Debug

Version 1.3
19-Mar-2021

Figure 32 SyS-T Instances in a Target System ............................................................................... 52
Figure 33 Gigabit Debug Functional Block Diagram .................................................................... 55
Figure 34 GbD in a Multiple-Node Network ................................................................................. 56
Figure 35 Gigabit Debug and the MIPI Architecture ..................................................................... 57
Figure 36 Debug for I3C in the MIPI Debug Architecture............................................................. 59
Figure 37 Debug for I3C Functional Block Diagram ..................................................................... 60
Figure 38 Example Target System with Multiple Network Adaptors............................................. 61vi

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

TablesTable 1 Summary of Test/Debug Capabilities Supported by NIDnT ............................................. 30
Table 2 Comparison of SneakPeek Protocol Styles........................................................................ 37

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

vii

Architecture Overview for Debug

Version 1.3
19-Mar-2021

Release History
Date

Version

14 February 2014

v1.0

Board approved release

29 September 2016

v1.1

Board approved release

29 August 2018

v1.2

Board approved release

19 March 2021

v1.3

Board approved releaseviii

Description

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

1

Overview

1.1

Scope

1
2
3
4
5
6

Recent technological developments have resulted in a quantum leap in the complexity of SoCs. Systems
that were formerly deployed on one or more PCBs are now being instantiated as single discrete devices.
While this trend is in general a boon to manufacturers and consumers of various systems, it has greatly
increased the complexity of system debug and optimization. Signals and interfaces that used to be visible attest points on a PCB are now deeply embedded inside a SoC. The use of tried and true methods of probing
buses and signals with dedicated Debug and Test equipment is now virtually impossible.

7
8
9
10

This increase in debug complexity is being addressed by IP vendors, SoC developers, OEMs and tools
vendors. New technologies are being deployed that provide the visibility required in these complex anddeeply embedded designs. In order to maximize the utility and efficiency of debug, converging on common
interfaces and protocols used by these new technologies is essential.

11
12

22
23

To meet this need, the MIPI Debug Working Group (Debug WG) are developing a portfolio of standards
and other documents that address the particular needs of debug. Some of the areas of focus are listed below.
• Minimizing the pin cost and increasing the performance of the basic debug interface• Increasing the bandwidth, capability and reliability of the high-performance interfaces used toexport high bandwidth, unidirectional debug data (e.g., processor trace data) to the debug tools• Deploying debug connectors that are physically robust and have the performance required for thehigh bandwidth demands of modern debug technologies• Developing generic trace protocols that allow many different on chip trace sources to share asingle trace data flow to the debug tools• Maximizing debug visibility in fielded systems by reusing some of the functional
interfaces/connectors for debug• Utilizing the new high bandwidth functional interfaces being deployed on various systems as atransport for debug

24
25This document provides an overview of the efforts to address these goals and provides summaries of the
documents that address them in detail.

13
14
15
16
17
18
19
20
21

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

1

Architecture Overview for Debug

Version 1.3
19-Mar-2021

26
27
28

2

Terminology

2.1

Definitions

1149.1: Short for IEEE 1149.1. See [IEEE01].
1149.7: Short for IEEE 1149.7. See [IEEE02].
Application Function: All functions of the TS other than Debug and Test Functions.

29
30
31

Application Processor: A programmable CPU (or CPU-based system on a chip (SoC) which may include
other programmable processors such as DSPs), primarily, but not necessarily exclusively, programmed tocoordinate the application processing and user interface processing.

32
33

Application Software: Used here to mean the target resident code that runs on the target processor. This
includes the operating system as well as the program(s) running with the OS.

34
35
36

Basic Debug Communication: Debug communication needed through an 1149.1 (or equivalent) port only
to manage basic debug communication functions such as run control, hardware breakpoints andwatchpoints, and examining system state.

37
38
39

Boundary Scan: A production test mechanism where interconnects between chips or logic blocks in an
SoC are verified by forcing known test patterns into the system via a serial scan interface, activating a testmode, and then scanning out the resultant values to test against expected results.

40
41
42

Built-in Self-Test (BIST): On-chip logic function that verifies all or a portion of the internal functionalityof a SoC during production tests. BIST logic requires minimal interaction with external test infrastructuresand speeds up verification of complex SoCs.

43
44
45
46

Debug: To detect, trace, and eliminate SW mistakes. Also used to get an insight into an embedded
processor system for performance measurements and debug of system level hardware. Used in thisdocument in an inclusive way that encompasses stop/start/break/step debugging as well as non-halting
methods such as trace.

47
48

Debug Access and Control Subsystem (DACS): The subsystem that provides a path for the DTS to obtain
direct access to application visible system resources (registers and memory).

49
50

Debug and Test Controller (DTC): The hardware system that is responsible for managing
communications with a system being debugged (the Target System).

51
52

Debug and Test Function: A block of on-chip logic that carries out a debug function such as run control,
providing debug access to system resources, Processor Trace, or test capability.

53
54
55

Debug and Test Interface (DTI): The interface between the Debug and Test System (DTS) and the Target
System (TS). The interface enables access to basic debug communication, the trace port, streaming data
(input and output), and other debug or test capabilities.

56
57

Debug and Test System (DTS): The combined HW and SW system that provides a system developer
debug visibility and control when connected to a Target System. The system incorporates:• A host PC, workstation or other processing system, running the debug or test software, controlling
the Debug and Test Controller. See also: Debug and Test Controller (DTC).
• Debugger: The debugger software, part of the Debug and Test System. It interacts with the Debug
and Test Controller and provides the (graphical) user interface for operating the Debug and Test
Controller (like commanding single step, setting breakpoints, memory display/modify, tracereconstruction, etc.)

58
59
60
61
62
63
64
65
66
67

Debug and Test Target (DTT): A component in the Target System that implements one or more Debug
and Test Functions. The interfaces to Debug and Test Targets, where different from the DTI, are not within
the scope of this specification. Examples include the debug control module on a CPU, debug interface tosystem memory, or the configuration interface to an on-chip trace module.

2

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
68
69
70

Debug Instrumentation and Visibility Subsystem (DIVS): The subsystem that provides communicationand storage of data generated by debug instrumentation modules (like processor and system trace) in thetarget system.

71
72

Debug Physical Interfaces (DPI): The chip and board level interfaces used to connect the DTC to the onchip debug functions.

73
74

Double Data Rate (DDR): A parallel data interface that provides valid data on both the rising and fallingedge of the interface clock.

75
76
77

Electrical: The definition of:• Signal voltage levels, current drain and drive strength on inputs, outputs, and bi-directional pins
• Rise and fall times and expected loads for device pins.

78
79

Function Assignment: The mapping of functions to signals (and thus to pins as per the current Pin
Assignment, e.g., Debug port pin [5] = CLK = TRACECLK.)80
81

Function Select: The method by which the Basic Debug Communication channel can be switched between
use for Debug Functions and use for operations needed to configure the debug system.

82
83

Gigabit Trace (GbT): A system architecture that supports transporting trace data over high-speed
networks and transports. See [MIPI04a].

84
85

Gigabit Debug (GbD): A set of network-specific adaptor specifications for mapping SneakPeek andGigabit Trace to various functional networks.

86
87

Hardware Protocol: The signal protocol required for a Debug and Test Controller to correctly movecontrol or data information between the DTC and Target System.

88
89
90

High Bandwidth Connection: A Mating Connection, Pin Assignment and Electrical specification for fullfunctionality, high frequency, higher pin count connection between the Target System and the Debug and
Test Controller / TPA.

91
92

High-speed Trace Interface (HTI): The transport specification that defines the electrical and timing
characteristics of high-speed serial trace export interfaces. See [MIPI09].

93
94
95
96

IEEE 1149.7 (basic debug communication): Enhanced IEEE1149.1 Debug and Test communication
standard, configurable from 4 to 2 pins. The IEEE 1149.7 interface can be viewed as providing
functionality enhanced compared to 1149.1 for Basic Debug Communication and test and with fewer pins.
A two-way communication channel for exclusive Debug and Test uses. See [IEEE02].

97
98
99
100

Intellectual Property (IP): any patents, patent rights, trademarks, service marks, registered designs,
topography or semiconductor mask work rights, applications for any of the foregoing, copyrights,
unregistered design rights, trade secrets and know-how and any other similar protected rights in any
country. Any IP definition by MIPI Bylaws will supersede this local one.

101
102
103

Low Pin Count Connection: A Mating Connection, Pin Assignment and Electrical specification for Basic
Debug Communication and limited Trace Port functionality, lower frequency, low pin count connection
between the Target System and the Debug and Test Controller / TPA.

104
105
106
107
108
109

Mating Connection: The connector to be used, defined by specific manufacturer and part number. The
required keep out area for board design to enable unobstructed connector mating. The definition of cablecharacteristics and terminations may include the characteristics of a connection from the point it leaves an
output buffer in a chip on the target or host side, routing on a printed circuit board on the DTC or Target
System side, cabling between the signal source and destination, and any connections (via connectors) in thesignal path.

110
111
112
113

Min-Pin: An interface for Basic Debug Communication with a minimal number of pins (2), using either
IEEE 1149.7, SWD or I3C.
Mode Select: A method for selecting a different Mating Connection, a different operating mode, a different
electrical mode or a combination of these, for example switching between 1149.1 and 1149.7.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

3

Architecture Overview for Debug

Version 1.3
19-Mar-2021

114
115

Narrow Interface for Debug and Test (NIDnT): A signal-mapping specification that defines how to reuse
the functional interfaces commonly available on fielded systems for debug. See [MIPI05].

116
117

Nexus: An IEEE-ISTO 5001™ standard interface for embedded processor debug. The Nexus standard
includes support for Basic Debug Communication as well as instruction and data tracing. See [ISTO01].

118
119

Other Debug: Debug functions not covered by 1149.1, 1149.7 or the Trace Port for example off-chip
memory emulation.

120
121
122

Parallel Trace Interface (PTI): The interface specification that defines the electrical and timing
characteristics of trace export interfaces that consist of a single clock and multiple data signals. See[MIPI02].

123
124

Pin Assignment: The mapping of signals to pins, e.g., SIGNAL_NAME on pin number N. This may
include restrictions on allowable pin assignments.

125
126
127

130

Processor Trace: The non-intrusive capture and logging of the activity of an embedded processor and thesubsystem in which the processor resides. Processor trace generally consists of one or more of thefollowing trace types, but it is not limited to these:• Instruction (PC) Trace – Application execution flow can be reconstructed by processing the logged
information• Data Trace – Data access activity is captured at the processor boundary

131
132

The captured data is encoded for efficiency and this data is stored on-chip for later upload or immediatelytransmitted through a chip interface to an off-chip receiver.

128
129

133
134

Return Test Clock (RTCK): A non-standard extension to 1149.1 that provides a feedback path for pacing
transaction on the interface.

135

Serial Wire Debug (SWD): An interface used for Basic Debug Communication. See [ARM01].

136
137

Series Scan Topology: A connection scheme where the control signals on the debug interfaces areconnected in parallel, but the data signals are daisy chained.

138
139

Silicon Test Subsystem (STS): This subsystem supports communication between the DTS and the on-chiplogic used for production test (boundary scan, BIST, etc.).

140
141

Star Scan Topology: A connection scheme where both the control and data signals on the debug interfaces
are connected in parallel.

142
143
144

System Software Trace (SyS-T): A format for transporting software traces and debugging information
between a target system (TS) running embedded software, and a debug and test system (DTS), typically acomputer running one or more debug and test applications (debuggers and trace tools).

145
146
147

System Trace Module (STM): A system trace interface with capabilities to export SW (printf type) and
HW generated traces (e.g., PC trace and memory dumps). Typical implementation is 4-bit parallel double
data rate. The STM uses a nibble-oriented protocol called STP. See [MIPI03].

148

System Trace Protocol (STP): The protocol used with STM. See [MIPI03].

149
150

System on a Chip (SoC): An electronic system in which all (or most of) the functional modules areintegrated on a single silicon die and packaged as a single chip.

154
155

System Trace: In the context of this document, system trace refers to SW Instrumentation Trace and HWInstrumentation Trace.
• SW Instrumentation Trace:Message output from instrumented application code.
• HW Instrumentation Trace: Messages triggered by transactions/events on the SoC infrastructure(s)and other HW modules in the system.

156
157
158

Target System (TS): The system being debugged, up to the Debug and Test Interface (DTI). The TS might
be a discrete device (a chip) or a collection of 1 to N discrete devices grouped on a board or collection ofboards. The TS might also contain 0 to N individual Debug and Test Targets.

151
152
153

4

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
159
160

Test Access Port (TAP): The on-chip interface to Debug and Test resources. Both 1149.1 and 1149.7
support the concept of a Test Access Port.

161
162
163
164

Timing: The AC characteristics of debug signals at the pins of the target device. Includes skew, jitter, riseand fall times, data/clock alignment, set-up and hold times. While this is shown to be common between all
connectors, there will likely be some variation, for example the Gigabit connector might not have separate
clock and data pins.

165
166
167

Trace: A form of debugging where processor or system activity is made externally visible in real-time orstored and later retrieved for viewing by an applications developer, applications program, or, external
equipment specializing observing system activity.

168
169

Trace Channel: A group of one or more signals and a clock that move trace information from the TS to the
DTS. There may be more than one Trace Channel between the TS and DTS.

170
171

Trace Data Protocol: The implementation-specific encoding of a particular type of trace by a particular
module.

172
173
174
175

Trace Port: An output port for the transmission of real-time data indicating the operation of the target (e.g.,
program execution and/or data bus transactions). Data transmitted across the Trace Port may be generated
by hardware, software instrumentation, or by a mixture of the two. This does not include trace collected onchip for later upload.

176
177
178

Trace Port Analyzer (TPA): An external hardware unit for collecting data transmitted from the Trace Port.
The data might be stored locally in real time before uploading to the host debug tools for later analysis by
the user, e.g., a logic analyzer or a unit customized to record trace information would both qualify.

179
180

Trace Wrapper Protocol (TWP): A protocol that wraps trace from different sources into a single stream
for simultaneous capture by a single TPA. See [MIPI04] and [MIPI04a].

181
182
183

Trigger: An indication that a specific system event has occurred. A trigger may be an input to the TS, asignal within the TS, or an output from the TS. The response to the trigger is determined by the entity towhich the trigger is sent.

2.2

Abbreviations

184

e.g.

For example (Latin: exempli gratia)

185

i.e.

That is (Latin: id est)

2.3

Acronyms

186

AC

Alternating Current

187

BIST

Built-in Self-Test

188

CCC

Common Command Code

189

CPU

Central Processing Unit

190

DACS

Debug Access and Control Subsystem

191

DDR

Double Data Rate

192

DFT

Design for Test

193

DIP

Data Integrity Package

194

DIVS

Debug Instrumentation and Visibility Subsystem

195

DNI

Debug Network Interfaces

196

DPI

Debug Physical Interfaces

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

5

Architecture Overview for Debug

Version 1.3
19-Mar-2021

197

DSP

Digital Signal Processor

198

DTC

Debug and Test Controller

199

DTI

Debug and Test Interface

200

DTS

Debug and Test System

201

DTT

Debug and Test Target

202

GbD

Gigabit Debug

203

GbT

Gigabit Trace

204

HTI

High-speed Trace Interface

205

HW

Hardware206

I3C

Improved Inter Integrated Circuit

207

ID

Identifier

208

IEEE

Institute of Electrical and Electronics Engineers

209

IP

Intellectual Property

210

IPS

Internet Protocol Sockets

211

IPR

Intellectual Property Rights

212

ISTO

Industry Standards and Technology Organization

213

JTAG

Joint Test Action Group

214

microSD

Micro Secure Digital

215

MMC

MultiMediaCard

216

NIDnT

Narrow Interface for Debug and Test

217

nTRST

Not Test Reset

218

OFM

Original Functional Mode

219

OS

Operating System

220

PC

Personal Computer or Program Counter

221

PCB

Printed Circuit Board

222

PHY

Physical Interface

223

POR

Power on Reset

224

PTI

Parallel Trace Interface

225

RF

Radio Frequency

226

RTCK

Return Test Clock

227

SIM

Subscriber Identity Module

228

SoC

System on a Chip

229

SPP

SneakPeek Protocol

230

SPTB

SneakPeek Transfer Block

231

STM

System Trace Module

6

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
232

STP

System Trace Protocol

233

STS

Silicon Test Subsystem

234

SW

Software235

SWD

Serial Wire Debug

236

SyS-T

System Software Trace

237

TAP

Test Access Port

238

TCK

Test Clock

239

TCKC

Test Clock Compact

240

TCP

Transmission Control Protocol

241

TDI

Test Data Input

242

TDIC

Test Data Input Compact

243

TDO

Test Data Output

244

TDOC

Test Data Output Compact

245

TDP

Trace Data Protocol

246

TMS

Test Mode Select

247

TMSC

Test Mode Select Compact

248

TPA

Trace Protocol Analyzer

249

TS

Target System

250

TWP

Trace Wrapper Protocol

251

UDP

User Datagram Protocol

252

USB

Universal Serial Bus

253

WG

Working Group

2.4

Use of Inclusive Language

254
255
256
257

The MIPI Alliance is committed to the use of inclusive language in its specifications and documentation.
Terms such as “master” and “slave” are being replaced with better, more descriptive terms and the MIPI
Alliance is actively updating its documentation to use the new inclusive language. This document will nolonger include these non-inclusive terms and the reader will notice the new language.

258
259
260

Note that at the time of publication, not all the documents referenced in this document were updated. The
table below is a list of the legacy terms that have been updated in this document with the new inclusive
language.
Referenced Specification
Debug for I3C

STP

Legacy Term

New Term

MasterController

Multi-Mastering

Multiple Controller-capable

Slave

TargetMasterMajor Source

261

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

7

Architecture Overview for Debug

Version 1.3
19-Mar-2021

3
262

References

Note:
Public Release Editions are available for most of the following MIPI Alliance adopted specifications,
see links in respective sections.

263
264
265
266

[MIPI01]

MIPI Alliance Recommendation for Debug and Trace Connectors, version 1.10.00 andhigher, MIPI Alliance, Inc., 16 March 2011.

267
268

[MIPI02]

MIPI Alliance Specification for Parallel Trace Interface (PTISM), version 2.0, MIPI
Alliance, Inc., 3 May 2011.

269
270

[MIPI03]

MIPI Alliance Specification for System Trace Protocol (STPSM), version 2.2, MIPI
Alliance, Inc., 21 August 2015.

271
272

[MIPI04]

MIPI Alliance Specification for Trace Wrapper Protocol (TWPSM), version 1.00.00, MIPI
Alliance, Inc., 23 February 2010.

273
274

[MIPI04a]

MIPI Alliance Specification for Trace Wrapper Protocol (TWPSM), version 1.1, MIPI
Alliance, Inc., 3 September 2014.

275
276

[MIPI05]

MIPI Alliance Specification for Narrow Interface for Debug and Test (NIDnTSM), version
1.2, MIPI Alliance, Inc., 17 August 2017.

277
278

[MIPI06]

MIPI Alliance Specification for SneakPeekSM Protocol (SPPSM), version 2.0, MIPI
Alliance, Inc., 21 May 2019.

279
280

[MIPI07]

MIPI Alliance Specification for Gigabit Debug for USB, version 1.1, MIPI Alliance, Inc.,
12 October 2017.

281
282

[MIPI08]

MIPI Alliance Specification for Gigabit Debug for Internet Protocol Sockets, version 1.0,
MIPI Alliance, Inc., 20 May 2016.

283
284

[MIPI09]

MIPI Alliance Specification for High-Speed Trace Interface (HTISM), version 1.0, MIPI
Alliance, Inc., 10 March 2016.

285
286

[MIPI10]MIPI Alliance Specification for System Software Trace (SyS-TSM), version 1.0, MIPI
Alliance, Inc., 1 December 2017.

287
288

[MIPI11]MIPI System Software Trace (MIPI SyS-T) – Example Code, https://github.com/MIPIAlliance/public-mipi-sys-t, MIPI Alliance, Inc., last accessed 19 March 2021.

289
290

[MIPI12]MIPI Alliance Specification for Debug for I3C, version 1.0, MIPI Alliance, Inc.,
21 April 2020.

291[MIPI13]MIPI Alliance Specification I3CSM, version 1.1, MIPI Alliance, Inc., 27 November 2019.

292[MIPI14]MIPI Alliance Specification I3C BasicSM, version 1.0, MIPI Alliance, Inc., 19 July 2018.

293
294

[IEEE01]

IEEE Std 1149.1™-2013, Standard for Test Access Port and Boundary-Scan
Architecture, Institute of Electrical and Electronic Engineers, 2013.

295
296
297

[IEEE02]

IEEE Std 1149.7™-2009, Standard for Reduced-Pin and Enhanced-Functionality Test
Access Port and Boundary Scan Architecture, Institute of Electrical and Electronic
Engineers, 2009.

298
299
300

[ISTO01]

IEEE-ISTO 5001™-2012, The Nexus 5001 Forum™ Standard for a Global Embedded
Processor Debug Interface, version 3.0.1, IEEE- Industry Standards and Technology
Organization, 2012.

301[ARM01]

ARM® CoreSight™ Architecture Specification, version 3.0, ARM Limited, 2017.

8

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
302
303
304

[AUR01]

Aurora 8B/10B Protocol Specification, SP002 (v2.3), Xilinx, Inc., 145
http://www.xilinx.com/support/documentation/ip_documentation/aurora_8b10b_protocol_spec_sp002.pdf, 1 October 2014.

305
306

[USB01]

USB 3.1 Device Class Specification for Debug Device, Revision 1.0, http://www.usb.org,
14 July 2015.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

9Architecture Overview for Debug

Version 1.3
19-Mar-2021

This page intentionally left blank.

10

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

4
4.1
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333

Debug System
System Framework

The modern systems on a chip often have complex Debug and Test architectures. In a simplistic view, themodern SoC Debug and Test architecture can be broken down into the following major subsystems:• Debug Access and Control Subsystem (DACS) – This subsystem provides a path for the DTS toobtain direct access to application visible system resources (registers and memory). It also
provides bidirectional communication for configuration and control of debug specific modules in
the TS. The communication between the debug and the DACS is generally implemented via one of
the following (this is not an exhaustive list):• Serial scan via a dedicated Debug and Test interface on the device• Memory mapped using a dedicated debug interconnect or in some cases the application visible
system interconnect• A proprietary communication protocol and interface on the device boundary• Debug Instrumentation and Visibility Subsystem (DIVS) – This subsystem provides
communication and storage of data generated by debug instrumentation modules (like processor
and system trace) in the target system. DIVS communication path to the DTS is usually via highspeed serial or trace interfaces and is generally unidirectional.
• System Test Subsystem (STS) – This subsystem supports communication between the DTS andthe on-chip logic used for production test (boundary scan, BIST, etc.). Access to the STS isgenerally accomplished via serial scan.
• Debug Physical Interfaces (DPI) – The physical interfaces that support debug at the SoC
boundary and on the PCB.
• Debug Network Interfaces (DNI) – The internal interfaces that allow debug and trace data to betransmitted to and from the DTS on functional networks. This communication is with dedicatedintelligent resources (sometimes called the Debug Butler) that possibly:• Enable bare metal debug on systems where the normal functional communication management
is not yet functioning• Allow debug to minimize or eliminate the use of functional resources for managing debug
communications

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

11Architecture Overview for Debug

Version 1.3
19-Mar-2021

334
335

Figure 1 provides a top-level view of how all the pieces of the Debug and Test architecture are integrated
on a device.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

Debug and Test System
System Test Subsystem (STS)336

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 1 MIPI Debug Generic System Framework

12

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

High Perf
Debug I/Fs

Version 1.3

Architecture Overview for Debug

19-Mar-2021

4.2
337
338
339
340
341
342

The MIPI Debug and Test System

The MIPI Debug WG effort does not address all the functional blocks in the generic framework. The
Debug WG standards and recommendations focus on device and board interfaces and protocols. There isalso an effort to standardize on communications for debug instrumentation (i.e., trace protocols), but with ageneric approach that maintains compatibility with protocols that already exist. Figure 2 illustrates theareas of the framework that are targeted by the various MIPI Debug specifications and recommendations
addressed in this document.
System Functional/Application Modules

Core
Trace

TWP
Debug
ExportInterfaces

Debug
Buffer

SystemMemoryHTINIDnTPin Interfaces

PCB

Board Connector
Switched Functional andDebug I/Fs
Debug

Debug and Test System

System Test Subsystem (STS)

SystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC

Other
Trace

SystemTrace

HW
Instrument
ation

GigabitTrace

SneakPeek

Connectors

343

Instrumentation Interconnect

System Interconnect

Gigabit
Debug

SyS-T

STP

Debug Interconnect

NIDnT
Board Connector
Basic Debug
Comms I/Fs

SW
Instrumentation

Debug
for I3C

Chip TAP

IEEE
1149.7

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Board Connector
High PerformanceComms I/Fs

Board Connector PTI

Debug
Connectors

High Perf
Debug I/Fs

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 2 MIPI Debug Documentation and the Debug Architecture

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

13

Architecture Overview for Debug

Version 1.3
19-Mar-2021

344
345
346
347
348

Figure 3 shows a more detailed block diagram showing how the generic debug framework can be realized
across an entire multiple-chip system. The devices share the basic debug, trace and functional interfaces.
Basic run control can be provided via the shared debug connection. Trace transport can utilize a shared link
dedicated to trace or a standard application visible network. In all cases, the footprint of the debug interface
to the tools is greatly reduced.
SOC

SOC
Basic
Debug
Functions

Basic
Debug
Port

Trace
Functions

Basic
Debug
FunctionsApplication
Functions

Network
Stack
Trace Port

Basic
Debug
Port

PHY Port

SharedParallel
Trace

Basic Debug

Basic
Debug
FunctionsApplication
Functions

Network Stack
Trace PortPHY Port

Application
And Trace OverHS Link
Basic Debug

SOC

Trace
FunctionsSharedParallel
Trace

PHY Port

Basic
Debug
Port

PHY Port

Application
And Trace OverHS Link

Basic Debug

Debug and Test System

Figure 3 Example MIPI System Overview

14

Application
Functions

Trace PortPHY Port

Network
Stack

Application
And Trace OverHS LinkConnector(s)

349

Trace
Functions

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

SharedParallelTrace

Version 1.3

Architecture Overview for Debug

19-Mar-2021

5
5.1
5.1.1

Debug Physical Interfaces (DPI)
Parallel Trace Interface (PTI) Specification
Trace and Debug Overview

364
365

It has become an accepted axiom that as the complexity of an embedded system increases, the need forsystem 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 thisinterface often allows developers to reconstruct (or “trace”) some portion of system activity, these types ofinterface 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 commonlyreferred 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.

366
367
368

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 ofthis document, the trace interface will subsequently be referred to as the Parallel Trace Interface or PTI.

350
351
352
353
354
355
356
357
358
359
360
361
362
363

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

15

Architecture Overview for Debug

Version 1.3
19-Mar-2021

5.1.2
369
370

Relationship to MIPI Debug Architecture

Figure 4 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
PTI specification.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector PTI

High PerformanceComms I/Fs

Debug and Test System
System Test Subsystem (STS)371

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 4 PTI in the MIPI Debug Architecture

16

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

High Perf
Debug I/Fs

Version 1.3

Architecture Overview for Debug

19-Mar-2021
5.1.3
372
373
374
375
376
377
378
379
380
381
382
383
384

Trace Scenarios

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 5.
• Debug and Test Targets (DTTs) reside in the Target System (TS).
• Trace modules inside a DTT contain one or more HW sub-modules that capture the systemtransactions with the required data. See the Trace Collect block in Figure 5.
• One or more HW modules encode or compress the data into an implementation specificencoding(s). These encoding(s) are called the Trace Data Protocols (TDPs). See the Trace Format
block in Figure 5.
• 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 5.
• The DTC captures the data.
• The data is decoded and analyzed using the DTS.
Target System (TS) w/
Single DTT
Parallel Trace Interface (PTI)

Trace
Collect

Trace
Format

Trace
Export

Trace
Cable

P
T
I

Debug & Test
System (DTS)

Debugger
Debug & Test
Controller (DTC)

Trace Module

DTT

385

Serial, parallel,
Etherrnet, USB
connection

PC orWorkstation

Debug
Comm.
Link

Figure 5 Example System with PTI

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

17

Architecture Overview for Debug

Version 1.3
19-Mar-2021

386
387

Note that only HW modules directly responsible for producing the data and clock of a PTI are required to
implement a PTI. Figure 6 shows how the PTI implementation is dependent upon system configuration.

Embedded System
Trace
Module1

Trace
Module2

TraceModule3

Trace
Module4

Trace
Module5

Pin Manager/
Mux

Trace
Module 0

Trace
Module6

Trace
Interleaving andExport Module

PTI

PTI

PTI

To Connector and DTC

To Connector and DTC

To Connector and DTC

Module Implementing PTI

Module Implementing an
Internal PTI

PTI

Location of PTIPTI Interconnect

Module Implementing
Proprietary Interface

388

Proprietary Interconnect

Figure 6 PTI Layers within a System

389
390

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

391
392
393
394
395
396

The scenario for Trace Modules 1–3 is slightly more complex. Here multiple modules export trace througha device level pin manager or mux. This management logic is only responsible for controlling which pinson 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.

397
398
399
400

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 document.

18

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
5.1.3.1

Multi-Point Trace Connections

401
402
403
404
405

Version 2 of the PTI specification expands the interface description to include a shared trace connection
where multiple PTI interfaces are merged through a single connector on a PCB board. Multi-point PTIs arevery useful for supporting trace on fielded systems that have multiple trace-enabled ASICs but only a single
connector (with limited data pins) for interfacing to an external DTC. A standard example would be amobile terminal with an application and modem SoC and a single MIPI NIDnT connection.

406
407
408
409

Devices can be configured to drive data on a subset of the PTI signals on their boundaries. The PTI signals
are merged at the connector, but only one PTI is driving any given data signal. The clock for all theinterfaces is supplied from an external source (generally the DTC). Figure 7 shows an example with four
devices (each with 4-pin PTIs) sharing a connector with each of them only exporting on a single pin.

410
411
412

A similar configuration is shown in Figure 8, but in this scenario only two devices are active and the port isshared as 3 pins and 1 pin. These are just examples, and the multi-point routing scheme defined in thisdocument supports varying PTI widths and numbers of devices.

413

Providing these enhanced features requires new operating modes for the clock and data portions of a PTI.
• Clock Modes• PTI-out-clock Mode: The PTI sources the clock along with the data
• PTI-in-clock Mode: The clock for the PTI is an input to the module driving the PTI data
• Data Modes• Point-to-point Data Mode: Data indexes are fixed on the PTI• Multi-point Data Mode: Data indexes may shift across the PTI

414
415
416
417
418
419

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

19

Architecture Overview for Debug

Version 1.3
19-Mar-2021

Device

Trace

Pin
Mgr

Device
TRC_CLK

Trace

DATA1
DATA2

Connector

DATA0
Pin
Mgr

DTC

DATA3

Device

Trace

Pin
Mgr

Device

Trace

420

Pin
Mgr

Figure 7 Multi-Point PTI with 4-Pin Trace and Four Devices Sharing the Connector

20

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

Device

Trace

Pin
Mgr

Device
TRC_CLK

Trace

DATA1
DATA2

Connector

DATA0
Pin
Mgr

DTC

DATA3

Device

Trace

Pin
Mgr

DeviceTrace

421

Figure 8 Multi-Point PTI with 4-Pin Trace and Two Devices Sharing the Connector
5.1.4

422
423
424

Pin
Mgr

Detailed Specification

For details of the MIPI PTI, consult the document: MIPI Alliance Specification for Parallel Trace Interface,[MIPI02]. This specification is available to MIPI members and to the public through the MIPI website. The
public version of the specification can be found at: http://resources.mipi.org/mipi-pti-download.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

21

Architecture Overview for Debug

Version 1.3
19-Mar-2021

5.2
5.2.1

High-speed Trace Interface (HTI) Specification
Overview

425
426
427
428
429
430

Transferring data off-chip from high performance embedded microprocessor cores requires a data port with
sufficient trace data bandwidth. Parallel port implementations such as MIPI Parallel Trace Interface (PTI),[MIPI02], employ a clock synchronous parallel interface, using as many as 32 parallel data lines to provide
the required bandwidth. Increasing CPU clock speeds and use of multiple processor cores demand
increasing data port bandwidth, while at the same time the number of I/O pins used for the data port isbeing reduced to facilitate lower cost and a higher level of SOC/ASIC integration.

431
432
433
434
435
436
437

MIPI High-speed Trace Interface (HTI) is a serial implementation of the data port, taking advantage ofavailable high-speed serial interface technology used in interfaces such as PCI Express®, DisplayPortTM,
HDMI®, or USB, provides higher transmit bandwidth with fewer I/O pins compared with a parallel
implementation. Unlike protocol specifications in the MIPI Gigabit Debug portfolio, such as [MIPI08],
HTI is not designed to be used over the high-level protocols implemented by interfaces such as PCI
Express, but is intended to re-use the low-level physical high-speed portions of those interfaces, in a baremetal environment.
5.2.2

438
439

Relationship to the MIPI Debug Architecture

Figure 9 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
HTI specification.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

PCB

Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

Debug and Test System
System Test Subsystem (STS)440

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 9 HTI in the MIPI Debug Architecture

22

Debug
ExportInterfaces

HTI

Pin Interfaces
Board Connector

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

High Perf
Debug I/Fs

Version 1.3

Architecture Overview for Debug

19-Mar-2021
5.2.3

HTI Details

441
442
443

HTI defines a method to transport a single stream of trace information over a channel consisting of one toeight high-speed serial lanes, using the Aurora 8B/10B protocol [AUR01]. HTI uses the serial simplex
mode of Aurora to transmit data in one direction from TS to DTS.

444
445

The HTI specification supports transmission of either the MIPI STP [MIPI03] protocol or MIPI TWP[MIPI04a] protocol over an HTI channel.

446

The HTI specification consists of the following aspects:• The LINK layer, which defines how the trace is packaged into the Aurora 8B/10B protocol.
• The PHY layer, which defines the electrical and clocking characteristics.
• A programmer's model for controlling HTI and providing status information.

447
448
449
450
451
452
453

In addition to the trace information, the HTI LINK layer provides the ability to include:• Optional CRC data, to assist in detecting errors in the trace transmission.
• Optional User Flow Control messages, to indicate additional information about the trace data
stream.
5.2.4

454
455
456

Detailed Specification

For details on HTI, consult the MIPI Alliance Specification for High-speed Trace Interface (HTI),[MIPI09]. This specification is available to MIPI members and to the public through the MIPI website. The
public version of the specification can be found at: http://resources.mipi.org/mipi-hti-download.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

23

Architecture Overview for Debug

Version 1.3
19-Mar-2021

457
458
459

5.3

Debug Connector Recommendations

5.3.1

Dedicated Debug Connector Overview

Board developers, debug tools vendors and test tool vendors all benefit when the number of connectors andconnector pin mappings used to support Debug and Test is minimized. To this end, MIPI Alliance ispromoting a set of connectors and mappings that address a wide variety of debug use scenarios.
5.3.2

460
461

Relationship to the MIPI Debug Architecture

Figure 10 shows the standard MIPI debug architecture highlighting the functional areas addressed by theconnector recommendation.
System Functional/Application Modules

SW
Instrumentation

Core
Trace

Other
Trace

Debug Interconnect

Chip TAP

SystemTrace

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs
Debug

Connectors

Board Connector

High PerformanceComms I/Fs

Debug
Connectors

Debug and Test System

System Test Subsystem (STS)462

Board Connector

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 10 Connectors in the MIPI Debug Architecture

24

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

High Perf
Debug I/Fs

Version 1.3

Architecture Overview for Debug

19-Mar-2021
5.3.3
463
464
465
466
467
468
469

Basic Debug Connectors

As the connector was not part of the original IEEE 1149.1 JTAG standard, a large number of different
JTAG connectors have emerged. The MIPI recommendation of standard connectors promotes convergence
toward a minimum set of debug connectors. The scalable 0.05 inch Samtec FTSH connector family
provides a cheap, small and robust target connection and is available in many variants (including lockableones) from multiple connector vendors. The pin-out allows scaling of the debug connection to meetdifferent requirements. This includes very small footprint connections (down to 10 pins), legacy JTAG
support (including vendor specific pins) and system level trace support (STM).
Missing pin and Plug at pin 7
for key.

470

Figure 11 Basic Debug PCB (left) and Cable End Connector (34-pin Samtec FTSH)
5.3.4

High-Speed Parallel Trace Connectors

471
472

Many debug tools vendors support target systems with high-speed trace interfaces. These tools utilize anumber of different mating connectors.

473
474
475
476
477
478

The MIPI Alliance Recommendation for Debug and Trace Connectors, [MIPI01], document defines twoconnectors for supporting high-speed trace and basic debug. The first connector is only intended forbackwards-compatible designs. The second connector is recommended for new designs. The goal is to havethis recommendation define a “de facto” industry standard for the trace connection and thus lessen theburden on target system and tools developers that need to support a large number of different mating
connections.

479
480
481
482
483

The recommended trace connector is a 60 pin Samtec QSH/QTH connector. The signal to pin mapping,which is defined in the recommendation, supports one run control and several trace configurations. The
different trace configurations use up to 40 data signals and up to 4 clock signals. To minimize complexity,
the recommendation defines four standard configurations with one, two, three or four trace channels ofvarying width.

484

Figure 12 Recommended Samtec QSH/QTH Connector
Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

25

Architecture Overview for Debug

Version 1.3
19-Mar-2021

5.3.5
485
486
487
488

Detailed Documentation

For details of the MIPI recommended connectors and connector pin mappings, consult the document: MIPI
Alliance Recommendation for Debug and Trace Connectors, [MIPI01]. This document is available to MIPI
members and to the public through the MIPI website. The public version of the specification can be found
at: https://mipi.org/sites/default/files/MIPI-Alliance-Recommendation-Debug-Trace-Connectors.pdf.

26

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

5.4
5.4.1

Narrow Interface for Debug and Test (NIDnT) Specification
Overview

489
490
491

The MIPI Debug Working Group has standardized a way to utilize functional interfaces for debug or test.
This technology is called NIDnT (Narrow Interface for Debug and Test). It allows better debug support inproduction or near-production units.

492
493
494
495
496
497
498
499

NIDnT technology defines low pin count, reliable, and high performance, debug interfaces that can be usedin deployed systems. These interfaces provide access to basic debug, trace of application activity, and HW
test capability by reusing already existing functional interfaces. In some cases, these interfaces areaccessible at the packaged boundary. This technology provides the means to use functional interfaces for
either functional or debug purposes. One or more functional interfaces (e.g., MMC card slot for trace andUSB for basic debug) may be used to provide debug capability. NIDnT technology does not aim to replacecurrent technologies such as debugging via a serial interface (e.g., GDB using a UART, or on-device debug
agent).
5.4.2

500
501

Relationship to the MIPI Debug Architecture

Figure 13 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
NIDnT specification.
System Functional/Application Modules

SW
Instrumentation

Core
Trace

Other
Trace

Debug Interconnect

Chip TAP

SystemTrace

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Basic Debug
Comms I/Fs

Debug
BufferNIDnT

Pin Interfaces

PCB

Board Connector

SystemMemoryNIDnT

SystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)502

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 13 NIDnT in the MIPI Debug Architecture

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

27

Architecture Overview for Debug

Version 1.3
19-Mar-2021

5.4.3

NIDnT Details

503
504
505
506
507
508

NIDnT technology has the potential for changing the product development paradigm as it provides for theuse of one or more of a product’s functional interfaces for debug. This can extend the availability of the
debug capabilities used in the early stages of product development to the latter stages. This is especiallyvaluable when these interfaces are available at the boundary of the product’s actual physical enclosure in
the product’s final form factor. This change in the product development paradigm is described in thefollowing paragraphs.

509
510
511
512
513

During the early stages of product development, IEEE 1149.1/1149.7/SWD/I3C based basic debug, trace of
application activity, and software messages sent over simple streaming interfaces like serial ports are
typically used for debug. Historically, much of this product development is performed using test or
development boards. These boards provide dedicated and readily accessible Debug and Test interfaces forconnecting the tools. A system with a dedicated debug interface is shown in Figure 14.
TS

Application Interface

514

Function Driver

I/O Driver

Pin

Connector

Debug Interface

DTS

I/O Driver

Pin

Connector

SoC

Application

Figure 14 Example of System with a Dedicated Debug Interface

515
516
517

In most cases, a product’s final form factor does not have dedicated Debug and Test interfaces as theseinterfaces are not propagated to the boundary of the product’s physical enclosure. This hampers theidentification of bugs present at this point in the product development.

518
519
520

A product might include a proprietary JTAG connector that requires some disassembly (e.g., removing thebattery cover and battery) and the use of a test fixture. The physically invasive process of accessing thisconnector could itself cause bugs or RF performance issues to disappear, or new ones to appear.

28

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
521
522
523
524
525
526
527
528
529
530

Figure 15 shows how NIDnT technology extends the use of functional interfaces for Debug and Test
purposes. It creates 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 to the interface connects that function’s inputs and outputs to the interface.
Disconnecting either the normal function or debug function from the interface connects its inputs toinactive default values that create the function’s inert operation while leaving its outputs unused. For
example, a SoC could multiplex an IEEE 1149.7 Test Access Port (TAP) and a Parallel Trace Interface(PTI) over the functional I/Os that normally provide a microSD interface. In this case, the IEEE 1149.7
TAP could be used for both basic debugging and as a control channel for the trace function that utilizes the
PTI interface.
TS
SoC

I/O Driver

Pin

Connector

I/O Driver

Pin

Connector

Pin Management
Infrastructure

Debug Interface

Application Interface

531

532
533
534
535
536

DTS

Function Driver

Figure 15 Example of System with NIDnT Capability
It is expected that adapters will be used to connect a product’s NIDnT Interface (e.g., microSD interface, orUSB) to the MIPI Debug Connectors (as defined in [MIPI01]). The use of an adapter provides fordebugging the product in its final form factor with standard debug tools, as the adapter remaps the signals
presented by the tools on these standard debug connectors to the appropriate positions on the functional
connectors.
5.4.4

Debug and Test Capabilities Supported by NIDnT Overlay Modes

537
538
539

A NIDnT Interface supports an operating mode that provides all functional operation of the interface(Overlay Mode 0, also called the Original Functional Mode (OFM)) and one or more non-OFM Overlay
Modes (Overlay Modes 1 through n) providing debug and test capability.

540
541
542
543
544

The debug and test capabilities that can be supported with these Overlay Modes are listed below with theirassociated pin counts shown in parenthesis. These capabilities might be mixed and matched to provide one
or more combinations of debug and test capability within the limitations (pin count and drive
characteristics) of a specific functional interface or combination of interfaces. The combinations supported
for a specific NIDnT Interface are outlined in interface-specific sections of the NIDnT specification.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

29

Architecture Overview for Debug

Version 1.3
19-Mar-2021

Table 1 Summary of Test/Debug Capabilities Supported by NIDnT545

Interface with
Single-Ended Electricals

Capability

Interface withDifferential Electricals

2-pin (Min-Pin) Debug• IEEE 1149.7 [IEEE02]

4-pin High-Speed Debug• Vendor Defined Differential Debug• Serial Wire Debug [ARM01]• UART• I3C
Basic Debug• Vendor Defined Single-Ended Debug
5-pin Legacy Debug• IEEE 1149.1 [IEEE01]
6-pin Modified Legacy Debug• Modified IEEE 1149.1 Standard withreturn clock (deprecated)
Single-Ended Trace

Trace

User Defined• Parallel Trace Interface [MIPI02]• Vendor Defined Single-Ended Trace

High-Speed Trace• High-Speed Trace Interface (HTI)[MIPI09]• Vendor Defined Differential Trace

Vendor Defined Single-Ended

Vendor Defined Differential

546
547
548
549

The trace function can either run with a clock shared with the 2-pin Min-Pin debug interface or run with anindependent clock. If the focus is on maximum trace bandwidth, a shared clock provides the largest numberof trace data pins but ties the data rate of each data pin to the clock rate of the 2-pin Min-Pin debug
interface.

550
551
552

Non-OFM Overlay Modes that support debug, i.e., that switch some of the NIDnT Interface pins to being
used for Basic Debug signals, are called Debug Overlay Modes (see table in the NIDnT Specification,[MIPI05]).
5.4.5

553
554
555
556
557
558
559

The current version of the NIDnT Specification addresses the reuse of the following interfaces:• microSD• USB (USB 2.0 and USB Type-CTM)• Display (HDMI and DisplayPort (DP))
Future versions of the NIDnT Specification might support other interfaces including, but not limited to:• SIM (smart card)• UniPro
5.4.6

560
561
562
563

Functional Interfaces that are NIDnT Candidates

Detailed Specification

For details of NIDnT technology, consult: MIPI Alliance Specification for Narrow Interface for Debug and
Test (NIDnT), [MIPI05]. This specification is available to MIPI members and to the public through the
MIPI website. The public version of the specification can be found at: http://resources.mipi.org/mipi-nidntdownload.

30

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

6

Debug Access and Control Subsystem (DACS)

6.1

IEEE 1149.7 Debug and Test Interface Specification

573

The IEEE 1149.7 standard [IEEE02] supports the needs of both Debug and Test. It is a superset of theIEEE 1149.1 standard [IEEE01] and represents a natural evolution of this standard. This approachpreserves the industry’s hardware and software investments in the IEEE 1149.1 standard since its inception.
While this is not a MIPI specification, the min-pin debug effort started in MIPI, so it is included here tohelp complete the debug framework. The standard:• Provides a substantial, yet scalable set of additional debug related capability• Supports multiple connection topologies• Four-wire series or star
• Two-wire star
• Halves the width of the interface in two-wire star configurations while maintaining performance

574
575
576

Six capability classes (T0-T5) are supported, with the implementer selecting the capability classimplemented. A class defines both mandatory and optional capability. Class capability increases
progressively, with the capability of a class including the capability of all lower numbered classes.

577
578
579

Capability classes T0-T2 support operation with the four-wire Test Access Port (TAP) (defined by the IEEE
1149.1 standard) connected in a four-wire series topology. Each of these classes incrementally extends theIEEE 1149.1 capability while using only the Standard Protocol defined by the IEEE 1149.1 standard.

580

Capability classes T3 additionally supports deployment in a four-wire star topology.

581
582
583
584

Capability classes T4-T5 provide for implementing devices with either a four-wire TAP (IEEE 1149.1 style)or a two-wire TAP (unique IEEE 1149.7 style). Devices with the four-wire TAP configuration can be
operated in all connection topologies. Devices with the two-wire TAP configuration can be operated only ina two-wire scan topology.

585
586
587

590

The T4-T5 classes incorporate the Advanced Protocol. The Advanced Protocol provides for the joint use of
the TAP for real-time system instrumentation, classic debug, and test, using only the TCKC and TMSC
signals as it:• Redefines the functionality of the IEEE 1149.1 TCKC and TMSC signals• Eliminates the need for the TDIC and TDOC signals• Allows the use of the TAP for both scan and non-scan data transfers

591
592

The combination of a two-wire TAP and use of the Advanced Protocol provides the capability of a fivewire IEEE 1149.1 TAP using only two signals, plus additional system debug capability.

564
565
566
567
568
569
570
571
572

588
589

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

31

Architecture Overview for Debug

Version 1.3
19-Mar-2021

593
594
595
596
597

A high-level view of the IEEE 1149.7 interface connectivity between a DTS and TAPs within the TS isshown in Figure 16. Both the four-wire (wide) and two-wire (narrow) TAP configurations are shown with
an optional test reset signal. A deprecated non-standard return clock signal is also comprehended with thefour-wire configuration (the use of this and other non-standard signals is strongly discouraged by thestandard).

Debug and Test System

Narrow

Target System

Wide

nTRST

nTRST

TCK(C)TCK(C)IEEE 1149.7 TMS(C)
Circuitry
TDO(C)TMS(C)TDI(C)TDI(C)RTCK

RTCK

TDO(C)IEEE 1149.7
Circuitry

Although TCKC is shown as bidirectional it is sourced by either the DTS or the TS
Optional reset signal
Required for operation with standard/advanced protocols
Required for data transfers with standard protocol
Non-standard 1149.1 extensions (deprecated functionality)

598

Figure 16 DTS to TS Connectivity

599
600
601
602

All capability classes begin operation using the Standard Protocol. IEEE 1149.7 operation is compatible
with IEEE 1149.1 from power-up, with the function of TCK(C) and TMS(C) signals providing thefunctionality (or a superset thereof) of the TCK and TMS signals that is specified by the IEEE 1149.1
standard.

603
604

All IEEE 1149.7 based devices may be implemented in a manner that allows their use in system
configurations where there is:• A mix of components implementing different capability classes• A mix of connection topologies

605
606
607
608
609
610
611

The DTS can use facilities defined by the standard to determine the following:• The types of connection topologies deployed within the TS• The component mix with the TS:• 1149.1 components• 1149.7 components + class of each component

32

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
6.1.1
612
613

Relationship to MIPI Debug Architecture

Figure 17 shows the standard MIPI debug architecture highlighting the functional areas addressed by theIEEE 1149.7 standard.
System Functional/Application Modules

SW
Instrumentation

Core
Trace

Other
Trace

SystemTrace

HW
Instrument
ation

Debug Interconnect

Chip TAP

IEEE
1149.7

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)

614

616

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 17 IEEE 1149.7 in the MIPI Debug Architecture
6.1.2

615

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Detailed Specification

For details of the 1149.7 specification, consult the document: IEEE 1149.7 Standard for Reduced-pin andEnhanced-functionality Test Access Port and Boundary Scan Architecture [IEEE02].

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

33

Architecture Overview for Debug

Version 1.3
19-Mar-2021

6.2
617
618
619
620
621
622
623
624

The SneakPeek framework is intended to enable debugging of a Target System via standard network
connection. This is accomplished by moving a portion of the Debug and Test Controller function onto the
SoC. These embedded DTC functions can be reached by network communication links that previously havenot been leveraged for DTC-like debug. SneakPeek also leverages a significant portion of the on-chip
debug infrastructure. As a result, DTC tools that previously used dedicated debug links (e.g., 1149.7 or PTI)
can easily be ported to work in a SneakPeek framework through simple network adaptor layers. The
identical capabilities realized via the dedicated debug interfaces should be available via SneakPeek (withpossible performance penalties).
6.2.1

625
626

SneakPeek Specification

Relationship to MIPI Debug Architecture

Figure 18 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
SneakPeek specification.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

SneakPeek

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)627

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 18 SneakPeek in the MIPI Debug Architecture
6.2.2

Overview

628
629
630

The SneakPeek Protocol (SPP) is used to communicate between a Debug Test System (DTS) and a Target
System (TS). This communication facilitates using Debug Applications (typically software) within the DTS
to debug the operation of the TS.

631
632
633

The SneakPeek Protocol abstracts the system designer from dedicated debug communication interfaces
such as JTAG and replaces them with the familiar mechanism of address-mapped read and write
transactions to enable the Debug Applications to observe, interrogate and adjust the Target System. These34

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
634
635

transactions might be addressed to main system memory, special function memories, or address-mapped
peripherals within the TS.

636
637
638

If the system requires legacy dedicated debug communication interfaces to be used internally within part ofa system, then these could be constructed by a dedicated address-mapped peripheral within the Target
System that is then accessed by the DTS via SneakPeek.

639
640

Figure 19 illustrates the route by which one or more debug software applications in a DTS utilize
SneakPeek Memory Agents within a TS to perform address-mapped transactions for them.
SystemMemory

Other
Debug

Trace
Config

Mem/Reg
AccessCore
Debug

Debug Interconnect
System Interconnect

Other Clients

SneakPeek
Memory Agent

Other Clients

SneakPeek
Memory Agent

SneakPeek Command Engine
SneakPeek Network Adaptor
Network StackTS

PHY
Network connection

DTS

PHY
Network Stack
SneakPeek Network Adaptor
SneakPeek Manager
Other Clients

Other Clients

Transaction Mapping
Transaction Mapping
Transaction Mapping
Debug Application(s)Debug Application(s)Debug Application(s)

641

642
643
644
645

Figure 19 Overview of SneakPeek System
The basic communication units used by SneakPeek are SneakPeek Command Packets sent from the DTS to
the TS, and SneakPeek Response Packets sent from the TS to the DTS. To provide more efficientinteractions with the communication network, the DTS packs typically many Command Packets into asingle SneakPeek Transfer Block (SPTB) before handing this over to the network driver for transmission to

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

35

Architecture Overview for Debug

Version 1.3
19-Mar-2021

646
647

the TS. Similarly, the TS packs typically many Response Packets into a single SPTB for transmission to the
DTS.

648

Figure 20 shows how the SneakPeek Protocol is built on top of existing network infrastructure.

Debug
Application

Debug
Application

Debug
Application

Transaction
Mapping

Transaction
Mapping

Transaction
Mapping

Debug
Requests

System& Debug
Memory Maps
Address-mapped
reads & writes

Debug
Requests

SneakPeek
Manager
SneakPeek
Command
Packets
in SPTBs

SneakPeek
Response
Packets
in SPTBs

Network
AdaptorMemoryAgentsSneakPeek
CommandEngineSneakPeek
Response
Packets
in SPTBs

SneakPeek
Command
Packets
in SPTBs

SneakPeek
Network
Adaptor

Network Data
Transport Units

649

650
651
652
653
654
655
656
657
658
659

Network Data
Transport Units

Network
Stack

Network
Stack

PHY

PHY

DTS

TS

Figure 20 SneakPeek Protocol and Network Stacks in DTS and TS
In summary:• The DTS sends SneakPeek Command Packets grouped into SPTBs to the TS over a data
communication network.
• These Command Packets cause an action or effect in the TS, typically an address-mapped read or
write transaction. The Command Engine generates a Response Packet corresponding to eachCommand Packet (with some special case exceptions).
• The TS sends SneakPeek Response Packets grouped into SPTBs to the DTS over the data
communication network.
• The SneakPeek Packets in a stream have a defined order at their source and are interpreted in thisorder at their destination. The SneakPeek Protocol is not concerned with actual transmission order

36

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
660
661

over the physical or other layers of the network stack but assumes that the network reconstructs
the original order before handing off the SneakPeek Packets at their destination.
6.2.3

Protocol Styles

662
663
664
665
666
667
668

SPP version 2.0 introduces TinySPP, an “optimized” style of the SneakPeek Protocol focusing on low
bandwidth interfaces and “tiny” implementations. TinySPP provides a reduced feature-set (e.g., nosequence number, reduced access space, reduced direct addressing space, and no access size variability)and “coexists” with SPP version 1.0, or FullSPP. Reducing the size of the Command and Response Packets
is done by assuming certain behaviors and by placing some restrictions on these interfaces. These
restrictions and assumptions are usually acceptable as a tradeoff for a smaller and simpler implementation
more tailored for lower bandwidth and/or half-duplex interfaces.

669

The main differences between the TinySPP and FullSPP styles are shown in Table 2.
Table 2 Comparison of SneakPeek Protocol Styles
FeatureTinySPP

Number of Access Spaces

671
672
673

8 (3-bit field)

32 (5-bit field)

Sequence Number

N/A.
Additional requirements to
network:• Messages stay in order• Guaranteed Delivery• DTS/TS has to do bookkeeping for request/
response

Present

Standard Size Field

Chosen by TS

Different options

Size of Transaction Byte
Count (TBC) Field

7 bits

16 bits

Short Addressing

6-bit address replacement
supported.
Short addressing is required in a
TinySPP implementation

N/A

Packet Alignment

Byte aligned

16-Byte aligned

Shortest Packet Length

4 Bytes

16 Bytes

Usage in MIPI Specifications

Debug for I3C

GbD for USB, GbD for IPS

6.2.4
670

FullSPP

Detailed Specifications

For details of the SneakPeek Protocol, consult the document: MIPI Alliance Specification for SneakPeek
Protocol, [MIPI06]. This specification is available to MIPI members and to the public through the MIPI
website. The public version of the specification can be found at: http://resources.mipi.org/mipi-spp-v2download.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

37

Architecture Overview for Debug

Version 1.3
19-Mar-2021

This page intentionally left blank.

38

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

7
7.1
674
675
676
677
678
679
680
681
682

Debug Instrumentation and Visibility Subsystem (DIVS)
Instrumentation and Visibility Subsystem Overview

The DIVS is basically a network or interconnect that allows trace data to flow from various sources to thetrace data sink (generally the DTS). The DIVS architecture provides a rich set of features that can beutilized to effect this purpose:• Trace protocols such as the System Trace Protocol (STP) that provide a standard encoding for
trace from multiple different HW and SW sources.
• Trace merge protocols such as the Trace Wrapper Protocol (TWP) that can be used to combine
many different trace streams into a single stream of data for easy transport management.
• Trace network protocols like the Gigabit Trace (GbT) and network adaptor specifications thatdefine how trace data should be formatted for transport over standard network links.

7.2

System Trace Protocol (STP) Specification

687

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.
• Trace components monitoring activities outside the processor.

688
689

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.

690

695

The advantages of this shared approach are:• Reuse reduces the time and cost of designing new protocols, as well as IP and tools supportingthem.
• Commonality of features enables greater interoperability, for example by providing timecorrelation between multiple trace streams.
• A robust base protocol ensures common protocol design mistakes are avoided.

696
697
698
699

The STP specifications were developed to leverage the advantages listed above. STP was not intended tosupplant or replace the highly optimized protocols used to convey data about processor program flow,
timing or low-level bus transactions. It is anticipated that STP data streams will exist side by side withthese optimized protocols as part of a complete debug system.

683
684
685
686

691
692
693
694

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

39

Architecture Overview for Debug

Version 1.3
19-Mar-2021

7.2.1
700
701

Relationship to MIPI Debug Architecture

Figure 21 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
STP specifications.
System Functional/Application Modules

SW
Instrumentation

Core
Trace

Other
Trace

SystemTrace

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)STP
Debug Interconnect

Chip TAP

Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)702

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 21 STP in the MIPI Debug Architecture
7.2.2

Protocol Overview

703
704
705
706
707

STP was developed as a generic base protocol that can be shared by multiple, application-specific trace
protocols. STP was not intended to supplant or replace the highly optimized protocols used to convey data
about processor program flow, timing or low-level bus transactions. STP is designed so that its data streams
coexist with these optimized protocols as part of a complete debug system. The STP protocol is now in its
second generation (STPv2) which is backward compatible with the first generation.

708

STPv2 includes the following features:• A trace stream comprised of 4-bit frames (nibbles)• Support for merging trace data from up to 65536 independent data sources• Up to 65536 independent data Channels per Major Source• Basic trace data messages that can convey 4, 8, 16, 32, or 64-bit wide data
• Time-stamped data packets using one of several time stamp formats including:• Gray code
• Natural binary• Natural binary delta• Export buffer depth (legacy STPv1 timestamp that requires DTC support)• Data packet markers to indicate packet usage by higher-level protocols• Flag packets for marking points of interest (for higher-level protocols) in the stream

709
710
711
712
713
714
715
716
717
718
719

40

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
720
721
722
723
724
725
726
727
728
729
730

• Packets for aligning time stamps from different clock domains• Packets for indicating to the DTC the position of a trigger event, which is typically used to control
actions in the DTC; for example, to control trace capture• Packets for cross-synchronization events across multiple STP sources• Support for user-defined data packets• Facilities for synchronizing the trace stream on bit and message boundaries• Optional support for data integrity protection of the trace stream• Add data integrity package (DIP) to facilitate error detection over noisy connections• Platform Description ID (PDID) packet types to carry payload information identifying theplatform the trace was captured and describe the contained trace data formats to enable processing
tools to auto-detect the format of the individual traces received from the trace stream itself.

731
732

Figure 22 shows the conceptual hierarchy of the different terms described in this specification. The clouds
are elements from the data model.

733
734
735

A stream of STP packets generally contains data from a number of different Major Sources, which in turn
may each have a number of different Channels. These two levels of hierarchy may be used, for example, todistinguish different software applications (Channels) running on different processors (Major Sources).
Data
MarkerFlag

ChannelUser, PDID

Error

736

737
738

ChannelChannelMajor Source

ChannelMajor Source

STP stream

Trigger

Data
Integrity
Protection

Time sync

Figure 22 Conceptual Hierarchy of STP Major Sources and Channels
Figure 23 shows an example of a target system that utilizes a module implementing the System Trace
Protocol. In this example, the STP data is transferred to the DTC across a PTI.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

41

Architecture Overview for Debug

Version 1.3
19-Mar-2021

Target System (TS) with
Single DTT
Parallel Trace Interface (PTI)

Trace
Collect

Trace
FormatDebug & Test
System (DTS)

Trace
Cable

P
T
I

Trace
ExportDebugger
Debug & Test
Controller (DTC)

System Trace Module

Serial, parallel,
Etherrnet, USB
connection

Debug & Test Target (DTT)
Debug and Test Interface (DTI)

739

740
741
742

PC or
Workstation

Debug
Comm.
Link

Figure 23 STM in a Target System
The timing diagram in Figure 24 shows an example of the STP packets that might be transferred to the
DTC in such a system. This example shows the end of a synchronization sequence followed by a series of
16-bit data packets on Channel 4 of Trace Source (Major Source) 3.
1111

1111

1111

0000

1111

End of ASYNC

0000

0000

0100

0001

VERSION = 4

0011

0000

0100

0101

C8 = 40000

0011

M8 = 3

0001

0010

0011

D16 = %x1234

0100

0101
D16

Time

743

Figure 24 Example STP Packet Sequence
7.2.3

Detailed Specification

744
745
746

In addition to the current version 2.2 of the MIPI STP Specification, version 2.3 is under development in
the MIPI Debug Working Group and is expected to be available in 2021. Version 2.3 will add a new
Platform Description ID packet for identifying the correct decoder(s).

747
748
749
750

For details of MIPI STP, consult the document: MIPI Alliance Standard for System Trace Protocol
Specification Version 2.2, [MIPI03]. This specification is available to MIPI members and to the publicthrough the MIPI website. The public version of the specification can be found at:
http://resources.mipi.org/mipi-download-system-trace-protocol.

42

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

7.3
7.3.1

Trace Wrapper Protocol (TWP) Specification
Overview

751
752
753
754
755
756
757

The Trace Wrapper Protocol (TWP) enables multiple source trace streams to be combined (merged) into asingle trace stream. The basic principle is that the source trace streams (byte streams) can be assigned
system unique IDs. A wrapping protocol is then used to encapsulate all the streams in the system
identifying them with these IDs. This protocol also includes provisions for synchronizing the merged
output stream and providing inert packets for systems that cannot disable continuous export of data. It has
optional facilities for indicating to the Debug and Test Controller (DTC) the position of a trigger event,which is typically used to control actions in the DTC, for example to control trace capture.

758
759
760
761

765

This specification is complementary to the MIPI Alliance Specification for Parallel Trace Interface (PTI),[MIPI02], and to the MIPI Gigabit Debug network adaptor specifications, such as [MIPI07]. It is intended
to be used by any module or layer that merges multiple trace data streams. The ultimate destination of themerged streams might include:• Host debug tools via a dedicated trace export interface (PTI)• On-chip capture into a dedicated trace buffer• On-chip capture into general system memory• Host debug tools via a functional network (GbD)

766
767
768

This specification is also complementary to the MIPI Alliance Specification for System Trace Protocol,[MIPI03], enabling a trace output to be shared between sources that implement STP and logic that
implements other trace protocols.

769
770

This specification is equivalent to the Trace Formatter Protocol specified in the Arm® CoreSight™
Architecture Specification, [ARM01].

762
763
764

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

43

Architecture Overview for Debug

Version 1.3
19-Mar-2021

7.3.2
771
772

Relationship to MIPI Debug Architecture

Figure 25 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
TWP specification.
System Functional/Application Modules

Core
Trace

Instrumentation Interconnect

TWP

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Pin Interfaces

PCB

Board Connector
Switched Functional andDebug I/Fs

Board Connector
Basic Debug
Comms I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)

773

775
776
777
778
779
780
781
782
783
784
785
786
787
788

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 25 TWP in the MIPI Debug Architecture
7.3.3

774

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)TWP Features

The features of TWP are summarized below:• Allows up to 111 source trace streams to be represented as a single stream and later separated byeither hardware or software.
• Requires low additional bandwidth.
• Minimizes the amount of on-chip storage required to generate the protocol.
• Permits any source trace stream to be used, regardless of its data format.
• Is suitable for high-speed real-time separation of the component trace streams.
• Is a bit stream that can be exported using any transport that supports bit stream data.
• Can be efficiently stored to memory whose width is a power of two for later retrieval.
• Has facilities for synchronization points so decode can be accomplished even if the start of the
trace is lost.
• Has facilities for indicating to the Debug and Test Controller (DTC) the position of a trigger event,which is typically used to control actions in the DTC, for example to control trace data capture.
• Has facilities for padding the data output for scenarios where a transport interface cannot be idled,and valid data is not available.

44

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
7.3.4

TWP Description

789
790
791

Each trace source, whose output is to be wrapped by TWP, is given a 7-bit trace source ID. The traceconsists of a number of Trace Fragments, each consisting of an ID indicating the source of the trace and at
least one byte of data.

792
793
794

If the source trace stream cannot be naturally represented using a stream of bytes, then an additional
protocol specific to the source trace stream has to be implemented in order to convert the source tracestream into a stream of bytes.
7.3.5

795
796
797
798
799
800

Layers

TWP is split into the following layers:• Layer T1: Flow Control. This layer enables TWP to be used over a connection which requires
continuous communication, for example PTI in situations where the clock cannot be stopped.
• Layer T2: Alignment Synchronization. This layer enables the alignment of frames in Layer T3 to
be determined.
• Layer T3: Data. This layer conveys trace data using 128-bit frames.
Interleaved
trace streams

T3
T2
T1

801

803
804
805

Trace sinkwith flow control

Trace sinkwith alignment

e.g. PTI continuously
supplied with data

e.g. PTI where clock
can be stopped.

e.g. storage inmemory on 16-byteboundaries.

Figure 26 Example Use Cases for Layers T1, T2 and T3
7.3.6

802

Trace sink
without flow
control

Detailed Specification

For details of MIPI TWP, consult the document: MIPI Alliance Specification for Trace Wrapper Protocol,[MIPI04] and [MIPI04a]. This specification is available to MIPI members and to the public through the
MIPI website. The public version of the specification can be found at: http://resources.mipi.org/mipi-twpdownload.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

45

Architecture Overview for Debug

Version 1.3
19-Mar-2021

7.4
7.4.1

Gigabit Trace (GbT)
Summary

806
807
808
809
810
811
812
813

One of the primary functions of the DIVS is to provide means to organize on-chip data and transport it toan external Debug and Test System for analysis. Historically, this data path used dedicated interfaces on the
SoC boundary (the Parallel Trace Interfaces introduced earlier). In some system scenarios, however, it isdesirable to transport the trace data via networks and interfaces which are shared with traffic sent by the
mission mode (normal) functions of the device. Leveraging functional interfaces and transports for debug
enhances the capabilities of the debug systems in scenarios where debug over dedicated interfaces isdifficult or impossible. Gigabit Trace (GbT) focuses on the sharing of standard communication channels fordebug.

814
815
816

The GbT architecture is a layered system. The GbT System facilitates packaging trace data as a stream of
GbT Network messages suitable for transport over a shared network and/or interconnect. It defines a
network independent set of data packets that are shared (but not required) by all network transports.

817
818
819
820
821

A Gigabit Trace system also requires a Network Adaptor that consumes GbT Network Messages andproduces a message stream compatible with the targeted transport. The network adaptor layers are generally
called Gigabit Debug Adaptors since they often support other network capable debug protocols like
SneakPeek. The goal is to define MIPI Gigabit Debug network adaptor specifications for all the common
transports found in different systems.
7.4.2

822
823

Relationship to MIPI Debug Architecture

Figure 27 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
Gigabit Trace specifications.
System Functional/Application Modules

SW
Instrumentation

Core
Trace

Other
Trace

Gigabit
Trace

SystemTrace

HW
Instrument
ation

Debug Interconnect

Chip TAP

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

Board Connector
Basic Debug
Comms I/Fs

Board Connector

PCB

Switched Functional andDebug I/Fs

Board Connector
High PerformanceComms I/Fs

Board Connector
High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)824

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 27 Gigabit Trace and the MIPI Debug Architecture46

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
7.4.3

Gigabit Trace System Overview

825
826
827
828
829
830
831

The TWP has facilities to readily adapt trace streams for export over the high-speed network interfaces
present on different systems. As these functional interfaces are now supporting extremely high data rates,
the term Gigabit Trace (GbT) has been coined. In a GbT system, the trace stream can co-exist on the
network link with other (functional) data traffic and the debug tooling is an application layer client on the
network. This approach enables trace capture in fielded systems where dedicated debug connections are notavailable. It also enables trace capture in the DTS using any host system (such as a high-performance PC)
that supports a high-speed network interface and can store data at high data rates.

832
833
834
835

Figure 28 and Figure 29 show a typical GbT system and the data flow in the TS and the DTS. Thesefigures are abstract functional diagrams that illustrate data flow through the system. The individual blocks
only define functions that likely exist in the system, not HW or SW modules with defined interfaces andbehaviors.
Trace Source

Trace Source

Multiple
Trace
Streams

TWP
FramesTrace Source

Arbitration

Merge

Application
Function

GbT Network Adaptor

GbT
Network
Messages

Operating System

Functional
Network
Traffic

836

Application
Function

Network Stack

PHY

Network

Figure 28 Typical GbT Configuration and Data Flow (TS)Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

47

Architecture Overview for Debug

Version 1.3
19-Mar-2021

Trace Client

Trace Client

Trace Client

Multiple
Trace
Streams

TWP
FramesDemultiplex

Application
Function

Application
Function

GbT Network Adaptor

GbT
Network
Messages

Operating System

Functional
Network
Traffic

Network Stack

PHY

Network

837

Figure 29 Typical GbT Configuration and Data Flow (DTC and DTS)

838
839
840
841

Note that in the TS, the GbT data path may optionally use the low-level OS to merge trace data with other(functional) network streams. This is obviously more intrusive to the system function than a direct data pathto the lower levels of the network stack (also shown). A more SW-intensive system might ease thecomplexity of the HW required to support GbT and it is anticipated that both approaches will be utilized.

842
843
844
845

The MIPI GbT solution builds on the MIPI TWP data primitives. The MIPI GbT solution uses a GbT
Network Adaptor (in the TS and DTS) to isolate generic GbT from the properties of a specific Network
Stack. A typical GbT system might adapt trace for export over a USB interface (USB 2.0 or 3.0 dependingon bandwidth requirements).

846
847
848
849

The MIPI Debug Working Group will produce independent specifications defining how a GbT system canbe realized on various transport networks. These Adaptor specifications will provide the details on how to
map the GbT framework outlined in this Annex to specific constraints and capabilities of a particulartransport network.
7.4.4

850
851
852
853
854
855

Requirements Summary

A GbT system generally addresses the following requirements:• Provides a mechanism to convey high bandwidth trace data over a transport network.
• Compatible with a variety of transport networks.
• Packages trace data streams into network-independent messages.
• Builds on existing network protocol specifications (referred to as the functional or transport
network).
7.4.5

Detailed Specification

856
857

The details of the Gigabit Trace framework are outlined in an annex to the MIPI Alliance Specification forTrace Wrapper Protocol, version 1.1.

858
859

For details of the Gigabit Trace framework, consult the document: MIPI Alliance Specification for Trace
Wrapper Protocol, [MIPI04a]. This specification is available to MIPI members and to the public through48

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
860
861

the MIPI website. The public version of the specification can be found at: http://resources.mipi.org/mipitwp-download.

7.5

STP and TWP in the DIVS

862
863
864
865

At first inspection, it might seem that STP and TWP have significant functional overlap. Both support themerging of trace data from multiple trace sources. They also have facilities for stream synchronization andalignment. A more detailed analysis, however, reveals that the protocols are optimized for different
capabilities and the differences in the protocols complement each other in a complex trace infrastructure.

866
867
868
869
870
871

TWP has a very uniform packet structure that is optimized for encoding and decoding interleaved byte
streams. The protocol can be implemented easily in HW and the ability to switch active trace streams on
any byte boundary decreases the amount of buffering required to support frame creation. The fixed data
frame also simplifies mapping TWP to some other transport protocol payload (the GbT scenario). TWP isthus ideal for trace data paths where many high-bandwidth trace sources are merged before export on ahigh-performance link.

872
873
874
875
876

These high-throughput requirements extend into the DTS as well. The fixed frames of TWP enable efficient
decode of the captured trace stream. The DTC hardware can remove lower-level link maintenance packets(synchronization and padding) before the higher-level data is stored. This type of filtering is highly
desirable when supporting systems where constraints dictate that the trace interface cannot be halted (e.g., amulti-point data mode PTI).

877
878
879
880
881
882
883
884
885
886

While STP also supports merging of trace streams, the protocol also provides features that assist high-leveltrace protocol (e.g. time stamps, frame markers, and hierarchical source IDs). These features greatly
decrease the complexity at the trace source. These sources do not have to worry about supporting their own
methods of time stamping or frame marking within their own protocols. The hierarchical IDs enablesupport for complex trace topologies (e.g., software message traces from multiple processes on multipleCPUs). Supporting these features increases the complexity of a module merging the data from various
sources into an STP stream. Since the interleaving boundary for STP is the non-fixed STP message
boundary, the modules implementing STP might require significant buffering and pipelining to achieve
high throughput. STP is thus ideal for trace data paths that might not have extreme bandwidth requirements
but support many trace sources (such as SW threads or small HW modules) generating trace.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

49

Architecture Overview for Debug

Version 1.3
19-Mar-2021

887
888
889
890
891
892

Figure 30 shows an example of a DIVS architecture that uses the various MIPI protocols and specifications
in a layered approach to trace export. SW and HW messages, encoded as STP messages (comprised of STP
packets) are transferred on the trace interconnect. High-bandwidth processor trace byte streams are alsopresent on this interconnect. These various trace byte streams are interleaved using TWP and the packets
are either exported directly to the pins or collected into GbT Network Messages for adaptation to afunctional network protocol.
System Interconnect

HW
Instrumentation
ModuleCPU Core

Processor Trace

STP
Trace
Interconnect

SW
Instrumentation
ModuleCPU Core

Processor Trace

STP

Proprietary
Trace
Packets

Proprietary
Trace
Packets

Trace Wrapper
ModuleTWP

TWP

Network
Adaptor

Pin
ExportModuleNetwork Protocol

PTI

Network Transport
ModuleNetwork
PacketNetwork

Debug and
Test Controller
893

Figure 30 Example Trace Architecture

50

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

7.6
7.6.1

System Software Trace (SyS-T) Specification
Overview

894
895
896
897

System Software Trace (SyS-T) is a format for transporting software traces and debugging information
between a target system (TS) running embedded software, and a debug and test system (DTS), typically acomputer running one or more debug and test applications (debuggers and trace tools). SyS-T is primary an
OS independent software tracing protocol, but it can also be used on bare-metal or OS environments.

898
899
900
901

The purpose of SyS-T is to provide a common trace format to exchange information between a TS and a
DTS. SoCs contain many different software agents. For different operating systems there exist different,
specific tracing solutions. There is no common solution existing across different software/firmware andhardware agents. MIPI SyS-T is aiming to fill this gap.
7.6.2

902
903

Relationship to MIPI Debug Architecture

Figure 31 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
SyS-T specification.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

SyST

Instrumentation Interconnect

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC
Pin Interfaces

Board Connector

Board Connector

PCB

Switched Functional andDebug I/Fs

Basic Debug
Comms I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)904

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 31 SyS-T in the MIPI Debug Architecture

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

51

Architecture Overview for Debug

Version 1.3
19-Mar-2021

7.6.3

Usage

905
906
907
908
909
910
911

SyS-T provides a platform independent general purpose trace protocol and software instrumentation library.
SyS-T defines a variety of trace messages ranging from simple UTF-8 based text and printf() stylemessages to complex binary data payloads. SyS-T is suitable for trace data generation from non-OS, baremetal environments, as well as OS kernel and user mode software. The SyS-T specification enables vendor
independent trace debug tools development for environments that don’t already provide an established trace
standard. It does so by separating the trace generation on the TS from the decoding on the DTS into
independent tasks.

912
913
914
915
916
917

Today’s platforms or SoCs contain multiple agents that are producing traces send from a TS. Different
agents can be seen as independent from each other regarding trace generation. Additional logic like a trace
arbiter is used to combine the agents trace data fragments together into a single platform level data stream.
SyS-T does not replace the trace arbiter step. SyS-T is used directly inside the agents for generating the
SyS-T trace data the gets send to the trace arbiter. A system implementing SyS-T therefore owns one tomany independent SyS-T instances, depending on how many agents are using the SyS-T tracing method.
Application Processor

Other Trace Agents(Software or Hardware)
Trace AgentSyS-T

Application Software

Trace Agent

Trace Agent

Other Protocol

SyS-T

Trace Agent

OS/Kernel Software
Trace Agent

Other Protocol

SyS-T

Trace Agent

Other Protocol

Trace Aggregator

Transport to DTS

918

Figure 32 SyS-T Instances in a Target System
7.6.4

919
920
921
922
923

SyS-T Instrumentation Library

The SyS-T Data Protocol generation is provided by a portable “C”-Language based software library called
SyS-T Instrumentation Library [MIPI11]. The SyS-T Instrumentation Library provides a function style API(referred to as the SyS-T API) to software using pre-processor macros. This library serves as the reference
implementation for a SyS-T Data Protocol generator. The usage of this library is optional. Vendor-specificimplementations are allowed as long as the output is compatible with the SyS-T Data Protocol.

52

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
7.6.5

Detailed Specification

924
925
926

In addition to the current version 1.0 of the MIPI SyS-T Specification, version 1.1, is under development in
the MIPI Debug Working Group and is expected to be available in 2021. Version 1.1 will include an
additional MIPI SyS-T packet type to support sending pure binary data packets.

927
928
929
930
931

For details of SyS-T technology, consult: MIPI Alliance Specification for System Software Trace (SyS-T),[MIPI10]. This specification is available to MIPI members and to the public through the MIPI website. The
public version of the specification can be found at: http://resources.mipi.org/mipi-sys-t-download. In
addition to the specification, the Open Source code for the SyS-T Instrumentation Library with an example
implementation is posted on GitHub, [MIPI11].

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

53

Architecture Overview for Debug

Version 1.3
19-Mar-2021

This page intentionally left blank.

54

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

8

Debug Network Interfaces (DNI)

8.1

Gigabit Debug (GbD) Specification

8.1.1

Overview

932
933
934
935
936
937
938

Gigabit Debug (GbD) is the blanket terminology for mapping debug capabilities to a particular functional
network. Unlike NIDnT, the network interface and protocol stack function normally. Gigabit Debug justdefines how to adapt the SneakPeek and Gigabit Trace functions so that they can co-exist with othernetwork traffic (as normal application layer functions). While the goal of a GbD system is to minimize
intrusiveness of debug on regular system functions, it is acknowledged that some debug capabilities (liketrace) may require significant network bandwidth and will thus have the potential for significant impact tothe normal system.

939
940
941

946

The current effort focuses on mapping the network independent MIPI SneakPeek Protocol and Gigabit
Trace framework to networks commonly found in many systems. Some of the items addressed in Gigabit
Debug Specifications include:• Connection/session initialization and de-initialization• Network link management• Packaging of MIPI protocol messages into network messages• Mapping aspects of Basic Debug and Trace functionality to network features• Network error handling

947
948

Figure 33 shows how the Gigabit Debug Adaptor specifications complement the specific MIPI debug
protocol specifications.

942
943
944
945

949

System& Debug
Memory Maps

Debug
Debug
Debug
Applications
Applications
Applications

Debug
Debug
Applications
Trace Clients
Applications

GbT
DriverSneakPeek
DriverGbT Network
AdaptorSPP Network
Adaptor

Debug
Debug
Applications
Trace
Sources
Applications

MemoryAgents

Trace
Infrastructure

SneakPeek
CommandEngineGigabit
Debug
Specifications

GbT Network
AdaptorSPP Network
Adaptor

Network
Stack

Network
Stack

PHY

PHY

DTS

TS

Figure 33 Gigabit Debug Functional Block Diagram

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

55

Architecture Overview for Debug

Version 1.3
19-Mar-2021

950
951
952

One of the fundamental features of GbD functionality is that it co-exists with non-debug network clientsand can operate quite effectively in multi-node networks that are commonplace today. Figure 34 illustrates
how GbD and non-debug network traffic are integrated in such networks.
DTS #1
Trace
Application(GbT #1)

GbT
Network
Adaptor

Network
DriverTS #1

Network
Controller

Other
Network
Client(s)Network
Controller

DTS #2

Network
DriverOther
Network
Client(s)DebugApplication(s)TraceApplication(GbT #2)

SPP
Network
Adaptor

GbT
Network
Adaptor

Network
DriverNetwork
Controller

Network

Network
Controller

Network
DriverNetwork
Controller

GbT
Network
Adaptor

GbT
Network
AdaptorGigabitTrace #1

SPP
Network
AdaptorSneakPeek
CommandEngine #2

TS #2

TS
Figure 34 GbD in a Multiple-Node Network

56

SneakPeek
CommandEngine #1

SPP
Network
Adaptor

DTS

953

SPP
Network
AdaptorCopyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

GigabitTrace #2

Version 1.3

Architecture Overview for Debug

19-Mar-2021
8.1.2
954
955

Relationship to MIPI Debug Architecture

Figure 35 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
Gigabit Debug specifications.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

SoC

GigabitDebug

Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)956

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 35 Gigabit Debug and the MIPI Architecture
8.1.3

Detailed Specifications

966
967
968
969
970

Currently, the Gigabit Debug Specification addresses the following functional networks:• USB• For details of the Gigabit Debug adaptors for USB, consult the document: MIPI Alliance
Specification for Gigabit Debug for USB, [MIPI07]. This specification is available to MIPI
members and to the public through the MIPI website. The public version of the specification canbe found at: http://resources.mipi.org/mipi-gbd-usb-download.
• Supports both a MIPI-defined extension to standard USB Descriptors and the Debug Device
Class Descriptor as given by the Device Class Specification for Debug, [USB01].
• TCP and UDP over Internet Protocols• For details of the Gigabit Debug adaptors for Internet Protocol (IP) sockets, consult the
document: MIPI Alliance Specification for Gigabit Debug for Internet Protocol Sockets,[MIPI08]. This specification is available to MIPI members and to the public through the MIPI
website. The public version of the specification can be found at: http://resources.mipi.org/mipigigabit-debug-for-ips-download.

971

Other functional networks will be addressed in future Gigabit Debug Specifications.

957
958
959
960
961
962
963
964
965

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

57

Architecture Overview for Debug

Version 1.3
19-Mar-2021

8.2
8.2.1

Debug for I3C
Overview

972
973
974
975
976
977
978
979

The Debug for I3C Specification describes methods for using the Improved Inter Integrated Circuit (I3C) asa minimal-pin interface to transport debug controls and data between a DTS and a TS. Current debug
solutions, such as JTAG [IEEE01] and Arm® Serial Wire Debug [ARM01], are statically structured whichleads to limited scalability regarding the accessibility of debug components/devices. Also, when looking at
the new requirements of near future technologies, such as 5G, and environments/markets, such as IoT, there
are gaps that need to be addressed. The Debug for I3C Specification targets these gaps and shortcomings byusing the capabilities of I3C to handle debug connectivity on buses that are dedicated for debug or sharedwith functional transfers, handling the debug network topology in a dynamic fashion.

980
981
982
983
984
985
986
987

The Debug for I3C Specification is designed in accordance with either v1.0 or greater of the MIPISpecification for I3C [MIPI13], or v1.0 or greater of the I3C Basic Specification [MIPI14].
Implementations can be used with I3C interfaces that implement either specifications. The Debug for I3CSpecification relies on the multi-controlling and multi-drop capabilities of the I3C Specification. The
Debug for I3C Specification uses the existing common command codes (CCC) as defined by [MIPI13] aswell as defining debug-specific CCC to handle debug communication and trace messaging. In-band
interrupts (IBI) are also used and debug-specific Mandatory Data Byte (MDB) values are defined as amethod of debug event and other communications initiated by the TS.

988
989
990
991
992

The Debug for I3C Specification allows for different designs where the I3C bus could be shared with nondebug communication. Whether the I3C bus is shared or dedicated for debug, the specification also allows
for different DTS access points and allows for an externally connected DTS. The ability for an I3C bus tohave multiple Controller-capable devices allows the DTS to be connected as either the Primary Controller(usually with dedicated debug I3C buses) or as a Secondary Controller (usually with shared I3C buses).

58

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
8.2.2
993
994

Relationship to MIPI Debug Architecture

Figure 36 shows the standard MIPI debug architecture highlighting the functional areas addressed by the
Debug for I3C Specification.
System Functional/Application Modules

Core
Trace

Other
Trace

SystemTrace

Debug Interconnect

Chip TAPSW
Instrumentation

HW
Instrument
ation

Other
Debug

Scan Interconnect

Trace
Config

Other
Debug
TAP

Mem/Reg
AccessTrace
Config
TAP

Core
Debug

Mem/Reg
AccessTAP

Boundary Scan
And BIST

Core
Debug
TAP

Debug
Kernel(s)Instrumentation Interconnect

System Interconnect

Debug
ExportInterfaces

Debug
Buffer

SystemMemorySystemNetwork(s)SoC

SystemFunctionInterfaces

Bus
Interfaces

ScanInterfaces

Debug
for I3C

Pin Interfaces

PCB

Board Connector
Basic Debug
Comms I/Fs

Board Connector
Switched Functional andDebug I/Fs

Board Connector

Board Connector

High PerformanceComms I/Fs

High Perf
Debug I/Fs

Debug and Test System
System Test Subsystem (STS)995

Debug Instrumentation and Visibility Subsystem (DIVS)

Memory Mapped Debug Access and Control Subsystem (M-DACS)

Debug Network Interfaces

Scan Based Debug Access and Control Subsystem (S-DACS)

Debug Physical Interfaces

Figure 36 Debug for I3C in the MIPI Debug Architecture
8.2.3

Target System Implementation Overview

1004

The Debug for I3C Specification allows for variations of adaptors for the different debug protocols. This
specification maps the following protocols:• SneakPeek: Used for debug communication with a SneakPeek Command Engine (TinySPP).
• TWP: Used for output of trace formatted using Trace Wrapper Protocol.
• STP: Used for output of trace formatted using System Trace Protocol.
• Simplified Address-Mapped (SAM): Simple address-mapped access to TS resources.
• UART: Virtual UART for character-oriented communication, e.g., scanf() and printf(), or a
GDB debug monitor.
• ImpDef: Implementation-Defined communication protocol.

1005
1006
1007
1008
1009
1010

The primary function of these adaptors (referred to as a Network Adaptor) is facilitating the transport ofdata between debug application layer entities at opposite ends of an I3C bus. The Network Adaptor maps
data objects that have meaning at the debug application layer to transport mechanisms provided by an I3C
bus. The Network Adaptor takes data from a debug application layer function and passes it to an I3C
protocol stack, or vice versa. This mapping preserves the relevant properties of the application data. A
Network Adaptor also provides control functions connected with system setup, initialization, and operation.

996
997
998
999
1000
1001
1002
1003

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

59Architecture Overview for Debug

Version 1.3
19-Mar-2021

1011
1012

Figure 37 shows how the Debug for I3C Specification complements the specific MIPI debug protocol
specifications with Applications and Debug Protocols above it, and I3C transport networks below it.

1013

Debug
Debug
Applications
Application(s)Applications

Debug
Debug
Trace
Applications
Applications
Application(s)

Debug
Debug
SneakPeek
Applications
Applications
Application(s)Driver n
Driver n
Driver

Trace
DriverSneakPeek
DriverNetwork
Network
Network
Adaptor
Adaptor
Adaptor

TWP/STP
Network
AdaptorSPP Network
Adaptor

System& Debug
Memory Maps

MemoryAgentsSneakPeek
CommandEngineDebug for I3CSpecifications

SPP Network
Adaptor

Debug
Debug
Applications
Trace
Sources
Applications

Debug
Debug
Applications
Sources
Applications

Trace
Infrastructure

Infrastructure
Infrastructure
Infrastructure

TWP/STP
Network
Adaptor

Network
Network
Network
Adaptor
Adaptor
Adaptor

I3C Transport &Network Layer

I3C Transport &Network Layer

I3C Link Layer

I3C Link Layer

DTS

TS

Figure 37 Debug for I3C Functional Block Diagram

1014
1015
1016
1017

Figure 38 shows an example Target System. This figure shows the standard I3C Target behavior (coloredyellow), the global debug functions (colored red), four Network Adaptors (colored purple), and theaccompanying debug functions (colored green for functions that are typically hardware and blue for thosethat are typically software).

1018

The Network Adaptors in this system are:• Index 0 is a SneakPeek Protocol (SPP) Network Adaptor transporting bytes formatted as
Command and Response Packets for a Command Engine using the TinySPP style.
• Index 2 is a System Trace Protocol (STP) Network Adaptor transporting data from an STM whichcontains trace produced by a SyS-T client.
• Index 4 is a Simplified Address-Mapped (SAM) Network Adaptor transporting bytes formatted as
Commands and Responses for a Debug Engine using the SAM Protocol.

1019
1020
1021
1022
1023
1024

60

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021
1025
1026
1027
1028

• Index 5 is a Trace Wrapper Protocol (TWP) Network Adaptor transporting trace data from two
trace sources that has been combined into a single stream using TWP.
• Index 14 is a UART Network Adaptor carrying character streams to and from scanf() andprintf() functions in an application program.

Trace
SourceSyS-T Software

Trace
SourceSneakPeek
EngineSTM

SAM Debug
EngineTWP Formatter

scanf()
printf()SneakPeek
Network Adaptor
Index 0STP
Network Adaptor
Index 2

SAM
Network Adaptor
Index 4

TWP
Network Adaptor
Index 5

UART
Network Adaptor
Index 14I3C Network & Transport Layer (i.e., I3C Target)

Debug-SpecificHandling

I3C Bus1029

Figure 38 Example Target System with Multiple Network Adaptors
8.2.4

1030
1031
1032
1033

Debug
Actions

Detailed Specification

For details of the MIPI Debug for I3C, consult the document: MIPI Alliance Specification for Debug for
I3C, [MIPI12]. This specification is available to MIPI members and to the public through the MIPI
website. The public version of the specification can be found at: https://resources.mipi.org/mipi-debug-i3cdownload.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

61

Architecture Overview for Debug

Version 1.3
19-Mar-2021

This page intentionally left blank.

62

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Version 1.3

Architecture Overview for Debug

19-Mar-2021

Participants
The following list includes those persons who participated in the Working Group that developed thisSupporting Document and who consented to appear on this list.
Bruce Ableidinger, SiFive

Stephan Lauterbach, Lauterbach GmbH

Christian Boenig, Lauterbach GmbH

Jason Peck, Texas Instruments Incorporated

Enrico Carrieri, Intel Corporation

Radu Pitigoi-Aron, Qualcomm Incorporated

Gary Cooper, Texas Instruments Incorporated

Matthew Schnoor, Intel Corporation

John Horley, Arm Limited

Eric Upson, Intel Corporation

Jason Kirschenbaum, Intel Corporation

Dan Wetzel, Western Digital Technologies, Inc.

Rolf Kuehnis, Intel Corporation

Past contributors to v1.2:
Eddie Ashfield, MIPI Alliance (Staff)

Stephan Lauterbach, Lauterbach GmbH

Enrico Carrieri, Intel Corporation

Andrea Martin, Lauterbach GmbHGary Cooper, Texas Instruments Incorporated

Laura Nixon, MIPI Alliance (Staff)

Patrik Eder, Intel Corporation

Jason Peck, Texas Instruments Incorporated

John Horley, ARM Limited

Norbert Schulz, Intel Corporation

Rolf Kuehnis, Intel Corporation

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.

Architecture Overview for Debug

Version 1.3
19-Mar-2021

This page intentionally left blank.

Copyright © 2014–2021 MIPI Alliance, Inc.
All rights reserved.