Specific “Debug for I3C” Implementation

The “Debug for I3C” Platform Interconnect Diagram Figure 4-3 describes how the system works. A Debug and Test System Host (DTS) connects into the USB Type-C connector. It establishes an I3C connection by negotiating with the PD controller to provide the Debug Accessory Mode. Debug Software on the DTS chooses to which device(s) to connect with over the I3C bus. Each Target System (TS) device uses its I3C IP block to establish and maintain communications with the DTS software. I3C packets with the debug messages are passed to the Debug Access Point IP which implements the appropriate “Debug for I3C” functions and interacts with its proprietary internal functionality. The TS can run different debug software supporting each device, or a single integrated software to interact with multiple devices.

The I3C messaging protocol supports both functional and debug traffic on the same physical bus. On initial “Debug for I3C” implementations, Intel is specifying that a single I3C physical bus be used to interconnect devices for debug traffic. This approach supports simplicity, provides deterministic bandwidth, and promotes reliability by not allowing functional traffic to interfere with debug traffic. Once debug use cases are well understood, Intel may allow sharing of debug and functional traffic on a single I3C bus.

Figure 4-3: "Debug for I3C" Platform Interconnect Diagram

The “Debug for I3C” Software Stack is described in Figure 4-4. The MIPI Specifications for I3C define the basic communication. The MIPI Debug for I3C extension defines how the debug modules communicate across I3C. The MIPI SneakPeek Protocol’s (SPP) command definition supports standard run control and probe mode applications. Software traces use standard MIPI System Software Trace (SyS-T) messaging over MIPI System Trace Protocol (STP) hardware protocol messaging.

Figure 4-4: Software Stack Implementation