Enrico Carrieri, Chair of the MIPI Debug Working Group
MIPI Alliance was well-represented at TestConX 2019, the premier conference on testing of integrated circuits, which took place in Mesa, Arizona, in early March. TestConX is in its 20th year and evolved from the BiTS (Burn-In & Test Strategies) Workshop to now include system-level testing and validation (hence, the name change).
I presented along with two of my colleagues from Intel – Rolf Kühnis, Senior Principal Engineer, and Brad Smith, Systems Architect. Our presentations focused on MIPI innovations for mobile device debug and test, including previews of two specifications coming this year that are optimized for low-bandwidth interfaces: MIPI Debug for I3CSM and MIPI SneakPeek ProtocolSM v2.0, which introduces the “TinySPP” style. TestConX gave us the opportunity to share these new technologies with the larger test and validation community.
MIPI is leading the mobile industry into a new generation with its range of interface specifications for devices with new capabilities and requirements. Our presentations introduced the next MIPI Alliance offerings to test those devices – Debug for I3C and SPP v2.0 – and described a standardized solution for closed-chassis debugging.
MIPI Debug for I3C
My presentation gave details of Debug for I3C, which will expand the applications of the MIPI I3C® interface into testing and debugging mobile and mobile-influenced devices. It is designed to overcome the limitations of current low-bandwidth solutions (e.g., UART, JTAG), offering an interface that is scalable and flexible enough to use in many scenarios throughout a product's lifecycle.
Low-bandwidth interfaces are growing more important for debugging and testing mobile devices as smaller and more power-constrained systems emerge, especially in the Internet of Things (IoT). For always-on, always-connected mobile devices, high-bandwidth connections may consume too much energy, and physical interfaces such as USB and Ethernet often are too big.
MIPI I3C, released in 2016, has several features that lend themselves to debug and test. It is an efficient two-wire interface that supports multi-mastering and includes hot-join capability so components can be smoothly reconnected after being powered down. It also supports in-band interrupts (IBI), which can indicate state changes or buffering thresholds.
Debug for I3C will add enhancements to I3C, including new common command codes (CCCs) for functions such as debug/test configuration and action/event triggers and interrupts. These additions will give developers several key advantages.
Target systems will be able to expose multiple debug and test ports over a single physical connection, making it easier to work on several components at a time. Debug for I3C will also allow for multiple entry points, giving OEMs different methods to access components at each stage of device development. For example, in the lab, a debug and test system (DTS) may be able to connect to a target system (TS) using I3C over a physical interface such as USB Type-C™. Later, when the system is in the field, it may not be possible to connect to it physically, especially for an IoT device. In that case, the DTS will be able to access it via the modem, using I3C over a wireless network.
Figure 1: Debug and test system diagram
Thanks to I3C's multi-mastering capability, and its byte-oriented interface ports that support different protocols, developers will not have to scrap their legacy debug and test infrastructure to use it. For example, one I3C port may talk to an existing UART machine and another to a JTAG network, so developers can enjoy both old and new debug capabilities.
Figure 2: Conceptual target system diagram
The new specification will work over either dedicated or shared bus topologies, and it will allow a DTS to send either broadcast or directed action requests, adding more flexibility. Further development work around I3C and debug is focused on a USB Device Class Specification for I3C mastering, which will allow a DTS to attach to a target system over standard USB Type-C connections.
Figure 3: DTS connecting over USB diagram
Also, the MIPI Debug Working Group is integrating debug and test extensions into the MIPI I3C HCISM (Host Controller Interface) specification, which allows for a common software driver interface for I3C host controllers from different vendors.
MIPI TinySPP
SneakPeek Protocol (SPP) v2.0, available later this year to MIPI Alliance members, will introduce TinySPP which is a style of MIPI SneakPeek ProtocolSM (SPP) v1.0 optimized for low-bandwidth and potentially high-latency interfaces such as I3C. In his presentation Rolf described the upcoming specification.
SPP is a packet-based communication protocol used between a DTS and a TS that replaces dedicated debug interfaces with address-mapped read and write transactions. SPP can be used by multiple debug applications to access components of a device through memory agents on the TS. To reduce latency, it uses pipelining to bundle several commands and responses into a single SneakPeek Transfer Block.
TinySPP will incorporate several features to better serve low-bandwidth interfaces. These will include a shorter minimum packet length of 4 bytes (versus 16 bytes), a smaller transaction byte count field of 7 bits (versus 16 bits), and a short addressing mechanism to reduce 64-bit or 32-bit addresses to 6 bits where possible.
Figure 4: Example SPP data format
The new style will also reduce the overhead involved in using JTAG to change state. New opcodes introduced into SPP v2.0 will use condensed commands to reduce the number of bits that need to be exchanged to complete a state change. This will work in a couple of ways. JTAG-based techniques often use "bit-banging" – exchanging a long series of ones and zeros – to go from one state to another. This approach is not efficient enough for low-bandwidth interfaces. In SPP v2.0, it will be possible to transmit the name of the desired state and let the system logic determine how to get there.
Similarly, to execute a polling loop that would otherwise require continually changing state, SPP v2.0 will be able to use a single command to set up the loop. Because it's no longer necessary to repeatedly go in and out of shift state, there is less data being sent, making SPP ideal for high-latency interfaces.
More on the way for closed-chassis debug
In his second presentation, Rolf discussed two closed-chassis debug methods for smartphones, which MIPI is currently standardizing. These techniques involve using the USB Type-C connection in either Debug Accessory Mode or an Alternate Mode based on MIPI Narrow Interface for Debug and TestSM (NIDnT), which will allow OEMs to debug new handset models in their final form factors, reducing cost and time to market.
Looking ahead
TestConX 2019 provided us a great venue to share about the MIPI innovations for mobile device debug and test. If you are interested in helping and influencing the direction of Debug for I3C or other debug and test projects at MIPI, please join the MIPI Debug Working Group.