11 Using SPIRIT for describing systems to debuggers DSDP meeting February 2006 Hobson Bullman – Engineering Manager Anthony Berent – Debugger Architect ARM - Development Systems © ARM Limited All rights reserved.

222 Overview Debuggers need to understand the system they are debugging. ___ Putting the descriptions in data files provides flexibility. ___ Using an open, standard, format for such data files allows the files to be created by SoC designers and shared between tools. ___ SPIRIT is an open standard that can describe systems at the appropriate level of detail. ___ ARM will be using SPIRIT in its debug tools, and promoting its wider use in debug tools.

333 The problem  Embedded systems used to be reasonably simple. e.g.:  1 processor  1 system bus  Etc.  Telling the debugger about such systems was reasonably simple.  Now:  Many processors  Many busses  Complex memory maps  So how do we debug complex systems?  We need the ability to debug all the processors, and to trace all the processors and busses

444 Debug hardware for complex systems  A complex system needs complex debug hardware  E.g. CoreSight is the ARM hardware solution to debugging complex systems:  Consistent architecture for debug and trace devices.  Bus structure allows all devices to share a single debug control port, and a single trace port.  But there is still a software problem:  How does the debugger know what components exist in the system?  How does the debugger know how the components are connected together?  How does the debugger know how to access the components?  Having lots of debug components in the system just magnifies this problem. ARM core DSP AMBA AXI/AHB AHB trace Cross Trigger Interface Cross Trigger Interface DAP CoreSight Debug ETM Trace buffer Trace bus (ATB) Trace port Funnel CoreSight Multi-source Trace JTAG Debug bus (APBv3) RAMROMI/O device ARM core I/O device Cross trigger matrix

555 Cross Trigger Interface Cross Trigger Interface ARM core What does the debugger need to know?  Programmers’ model:  System components  System busses  Base addresses  Device registers  Debug access description:  Debug access to processors  Other debug devices  Debug interconnections DSP AMBA AXI/AHB AHB trace DAP ETM Trace buffer Trace bus (ATB) Trace port Funnel JTAG Debug bus (APBv3) RAMROMI/O device Cross trigger matrix 0x x00x Reg 1

666 Data driven debugger configuration  With a large range of such complex systems it becomes impractical to explicitly build support of each system into the debugging tools.  Far better to build in support of the individual components, and to use a data file to describe the system  If the data file format is open then SoC designers or debugger users can create their own descriptions of new SoC  Ideally multiple tools, even from different vendors, should be able to read the same data files.

777 SPIRIT and debugger configuration  A SPIRIT system description can contain the information the debugger needs:  Component list.  Component interconnection.  Physical address maps.  Some extra usage conventions (e.g. names of debug interfaces) needed:  Under development by ARM, will be made publicly available.  Open standard, so the same descriptions can potentially be used by many tools.  Including ARM and non-ARM debug tools.  Reasonably simple XML format.  Hierarchical designs supported:  This allows separate subsystems to be described independently.  Standard SoC design tools are starting to support the creation and use of SPIRIT descriptions:  Hence the SPIRIT description can be easily generated during SoC design.

888 Typical data flows ETMCS for Tiger DAP for Tiger AHB Trace Funnel ETBCS EDA/ESL Tools Component I/O and memory map information as a SPIRIT XML File ETMCS for Tiger DAP for Tiger AHB Trace Funnel ETBCS IP Components Other topology tools: Manual file generation Proprietary tools Autodetect from SoC Emulator ETMCS DAP AHB Trace Funnel ETBCS DSP Topology and System Memory Map Description as SPIRIT XML Reads debug access descriptions from SPIRIT files Debugger Reads programmers’ model from SPIRIT files IP vendor System designer Software developer

999 Part of a SPIRIT design description instance ARM CoreSightSampleDesign Sample_design 1.0 Core_0 … …

10

11 SPIRIT for debug standardization  SPIRIT, in its current form, is useful for debug.  SPIRIT consortium steering committee looking at future activities:  Extension of scope to include software debug likely.  The main effect of this will be to allow consideration of debug requirements in future extensions to SPIRIT.  Possible areas for extensions to SPIRIT to improve debug support (none yet proposed to SPIRIT consortium):  Description of non-memory-mapped registers (e.g. co-processor registers or internal processor registers).  SPIRIT already supports some description of internal registers for hardware validation. This could possibly be extended to provide descriptions suitable for software debug.  Description of interrupt structure.  Explicit tagging of interfaces used for debug control

12 SPIRIT and ARM  SPIRIT descriptions are being developed for ARM IP:  Including processors, CoreSight components, busses.  ARM EDA tools support SPIRIT  ARM is a leading participant in SPIRIT consortium.

13 Conclusions  SPIRIT provides a vendor independent way of describing complex systems.  SPIRIT descriptions can contain the data needed to allow such systems to be debugged.  Adoption of SPIRIT descriptions for debug will allow easy multi-sourcing of both components and debug tools  ARM is developing support of SPIRIT in their debug tools, and is leading discussion within the industry on the potential use of SPIRIT as an open standard for debug target description