Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MIPI DevCon 2016: How MIPI Debug Specifications Help Me to Develop System SW


Published on

In this presentation, Norbert Schulz of Intel Corporation will discuss good system debug practices and different MIPI standards for creating state-of-the-art software debug solutions. Many software designers still arbitrarily insert text messages into their code to find errors in the same way as their predecessors did 40 years ago. With the Narrow Interface for Debug and Test (MIPI NIDnT), System Trace Protocol (MIPI STP) and System SW-Trace (SyS-T), a user can analyze IoT, automotive or mobile device software behavior in an easy, low-invasive manner through debug or functional ports, such as a USB Type-C™ connector.

Published in: Mobile
  • Be the first to comment

  • Be the first to like this

MIPI DevCon 2016: How MIPI Debug Specifications Help Me to Develop System SW

  1. 1. How MIPI Debug Specifications Help Me to Develop System SW Norbert Schulz Intel Corporation
  2. 2. Contents •  MIPI Alliance Debug WG Focus •  Good Debug Practices •  Example Use Case: Form Factor SW/FW tracing •  MIPI SyS-T Messaging (Trace creation) •  MIPI STPSM/ MIPI TWPSM data protocols (Trace arbitration) •  MIPI NIDnTSM (Trace export) •  Summary 2
  3. 3. MIPI Alliance Debug Workgroup Focus •  Enabling best system debug support in all stages of the Mobile and Mobile Influenced equipment: •  Low cost solutions •  Interoperability between tooling and devices by defining debug standards. •  The targeted interfaces are hardware and software interfaces interacting with or supporting system debug. •  Leveraging functional interfaces to increase debug visibility in fielded systems •  MIPI Alliance Debug Specification Scopes •  Physical interfaces for Debug/Trace •  Midlevel protocols for trace data transfer •  SW Trace instrumentation 3 Non-standard or proprietary solu1on in Debug leads to increasing development cost and extended -me to market.
  4. 4. Good Practices for Debug •  Make debug a platform capability •  Understand that debug is a customer visible feature •  Scale debug support with platform complexity •  Support Hardware/Software co-debug •  Avoid IP-block specialized solutions by •  Aligning trace message formats •  Unifying data capture methods (debug port and probes) •  Using debug/analysis tools supporting platform scope •  Using a shared time base to reconstruct historical message order •  Support closed-chassis / retail build debug •  Re-use of functional interfaces or their pins in form factor devices •  Have a runtime method to configure debug •  Enable / Disable of individual trace sources •  Trace verbosity control to meet bandwidth / trace audience constraints •  Retail build / field testing support 4
  5. 5. Example Use Case: Form Factor SW Tracing •  Capture platform boot logs from a tablet •  No dedicated debug port, reuses functional USB port for capture •  Messages originating from different areas •  Boot controller •  UEFI BIOS •  Using MIPI specifications for •  Trace generation •  Trace Arbitration •  Trace Export •  2 machine Demo Setup •  Target System (TS) •  Debug and Test System (DTS) 5 Target System (TS) Form Factor Device Debug and Test System (DTS) USB Connector pin capture probe
  6. 6. MIPI Specification Based Solution Overview 6 Merged and -mestamped message fragments CPU Core CPU Core CPU Core CPU Core Boot Controller Trace Arbiter Instrumenta-on Interconnect OS Apps Blocks SyS-T UEFI SyS-T SyS-T SyS-T Debug Clock STP USB Connector PIN Manager Debug Interface USB Func-on NIDnT Trace Genera-on Trace Arbitra-on Trace Export TWP Other Func-onal Blocks Other SW/HW Specifica-on support for all phases of TS debug data processing other data MIPI Specifica-on
  7. 7. Complete Specifications Overview 7
  8. 8. SyS-T - System Software Trace •  SyS-T defines a SW tracing methodology •  Addresses missing standard for SW tracing •  Only major OS have established vendor specific methods •  But SW is running in most IP blocks today •  Embedded System friendly •  Build, Target and Debug system distinction •  Bandwidth reduction by using DTS collateral for decode •  SyS-T includes •  A SW instrumentation API •  A data protocol for text and binary data •  A XML decode collateral definition •  Open Source reference code planned •  New MIPI Specification for SW tracing •  1.0 Release planned Q2’2017 8 Build Machine Debug and Test System (DTS) Target System (TS) Compiled SoOware SyS-T API SyS-T Encoder SyS-T Trace data SW Build SyS-T Decode Collateral SyS-T Decoder Trace Data Viewer SyS-T Standard Reference code Instrumented Source code Collateral creator Vendor independent and scalable SW tracing method
  9. 9. SyS-T - SW Instrumentation •  Reference code for C-Language •  Only 1 header needed (mipi_syst.h) •  Instrumentation calls are C-Macros •  API‘s for •  Text and binary messages •  C99 style printf() support •  Optional features (crc32 checksums, time stamps ...) •  IO-Channel concept •  Support for multi-channel output protocols •  Multi-threaded output without locking •  Trace Viewer Tool Result •  1 SyS-T call turns into 1 trace message •  Parameters turn into message fields •  Automatic time stamping 9 Create/destroy trace channel Message crea-ng Macros SW executed on TS Decoding result on DTS
  10. 10. SyS-T Decode Collateral SyS-T - Advanced Features •  Bandwidth optimized printf() •  Sends only numeric ID and parameters •  Format string stored in DTS collateral, not in compiled code •  Reduces space and bandwidth need •  24 byte string replaced with 4 byte catalog ID in shown example •  Protocol Tunneling •  Raw data write over SyS-T •  Example: Embed a kernel core dump image into trace stream •  Embedded Source Positions •  “Jump-to” instrumentation source code of a message 10 SyS-T Decoder Catalog parsing ... Compiled pseudo-code : trc_out(catalog_hdr) trc_out(0x1234) trc_out(42) <Message ID="0x1234“ File=“hello.c" Line=“3"> The meaning of life: %d </Message> Trace Data Stream Output: „The meaning of life: 42“ Ask for ID=0x1234 Receive catalog message data Compiling ...
  11. 11. STP - System Trace Protocol •  Robust trace data transport protocol •  Multiple trace data stream merging based on Master/Channel concept •  Up to 65536 Masters and up to 65536 Channels per Master •  Solves the problem of interrupt code tracing •  Channel switching avoids locking to make single message contiguous •  Provides common trace features •  Time stamping and correlation •  Message boundary marks and sync •  Transport data integrity and error indication •  Specification Status •  Currently at version 2.2, initial version 2006 •  Adoption Examples •  Hardware IP •  ARM® CoreSightTM, Intel® Trace Hub, etc. •  SW Tools Support •  ARM® DS-5, ASSET InterTech SourcePointTM, Intel® System Studio, Lauterbach, etc. 11 Low overhead and real 1me system friendly trace protocol providing common features * ARM is a registered trademark of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. CoreSight is a trademark of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. Intel and the Intel logo are trademarks of Intel CorporaCon or its subsidiaries in the U.S. and/or other countries. SourcePoint is a trademark of ASSET InterTech. Low overhead 4-Bit encoding Master/Channeel context Data for Master/Channel combina-on 3:4
  12. 12. TWP – Trace Wrapper Protocol •  Low level data merging protocol •  Combines up to 111 independent data streams identified by numeric ID •  16 Bytes data/ID packed frame structure •  Support for continuous data export to PIN interfaces •  Specification Status: Released 2010,Current version 1.1 •  TWP vs. STP Protocols •  TWP enables sharing of an output between different STP or other data streams •  TWP is data frame, STP is trace stream oriented •  Specifications are complementary, system may or may not use both of them 12 TWP Data Frame 16 Byte Frame: Efficient data stream merging for expor1ng to pin interfaces
  13. 13. NIDnT – Narrow Interface for Debug and Test •  Reuse functional interfaces for debug and test •  Form Factor device support •  No dedicated debug connectors available •  Low pin count support •  USB Type-CTM Receptacle •  USB 2.0 Micro-B/-AB Receptacle •  HDMI/DisplayPort Interface •  micro-SD Card Slot •  NIDnT defines •  Switching methods between original function and debug/test. •  Pin assignments •  Available since 2013 •  Current version 1.1 13 Dedicated debug port, Not available on a form factor device NIDnT func-onal port pin switching infrastructur * USB Type-C is a trademark of the USB-IF. Low cost pla`orm debug data access including form factor device support Device Func-onal port
  14. 14. NIDnT Support for USB Type-C •  Version 1.1 adds USB Type-C receptacle support for TS •  NIDnT defines unique Alternate Mode for debug overlays •  Uses USB PD structured Vendor Defined Messages •  To enter NIDnT debug Alternate Mode •  To control the multiplexing and overlays on the receptacle. •  MIPI Alliance owns a standard ID from the USB Implementers Forum for NIDnT. 14 Uses the standard USB Type-C Alternate Mode flow to support simultaneous debug and func1onal modes over a single receptacle
  15. 15. Video: Device Boot Phase Tracing 15
  16. 16. Summary •  MIPI Alliance Debug WG Specifications •  Provide platform level debug solutions •  with proven scalability from wearables/IoT to server systems •  that enable low cost debug integration •  support form factor device debug •  Establish standards for all debug data processing phases •  Cover trace data generation, arbitration and export •  Enable vendor independence between designs and tooling •  PIN capture interfaces (probes) •  Protocol decoders •  MIPI Alliance Debug Workgroup Links • •