Need for OCP-IP Debug Interface Standard

1. Need for OCP-IP Debug Interface Standard Proposal of the OCP-IP Debug Interface Study Group August, 2005

2. Questions to be Answered 1. Who will contribute to future work (group and …) 2. What we can do (recommended scope) 3. Open issues and warnings we all should know …, liabilities? (none) 4. Pros of forming a Working Group (WG) (OCP helps integrate SoC) 5. Why the WG’s work would be adopted and used and grow in industry acceptance. (win more market for debug providers, first and only debug-IP integration solution for system designers, …) Objective is to get an “Approving vote to form an OCP Debug WG”

3. The OCP-IP Debug Interface Study Group • FS2 Neal Stollon • DAFCA James Colgan, Al Crouch, Dave Orecchio • CAST/ Evatronix Hal Barbour / Wojtek Sakowski • TI Gilbert Laurenti • Toshiba Bob Uvacek, chair • MIPS Scott McCoy, John Hogan • Nokia Anssi Haverinen ______________________________________________ • OCP-IP contacts Jeff Phillips, Travis Spear, Ian Mackintosh

4. Summary of the Proposal to the GSC The OCP Debug Study Group Supports this Proposal: • Definition of a Debug Concept & its Technical Rationale • Present Debug Realizations And Standards in Appendix • Industry Adoption and Risk Reduction • Proposed Activity and Goals for an OCP-IP Interface • Remarks to Strategy, Business Model & Timeline Appendix: • Proposals of the Group Members • Block Diagrams of Existing Debug Solutions • Details

5. Bus CM / PM Core Debug IP CHIP JTAG/Nexus-Trace Debug Software SYS API EDA API Debug Definition: SoC Existing Single Debug Concepts

6. Definition of a Debug Concept • 3 OCP-Debug-IP connections to an OCP-SoC ( buses + cores + IP blocks) • CORE-INTERFACE: OCP interface to core or IP-block [run control and debug data/control]. Factor in interfaces to clock / Power management • BUS-INTERFACE: OCP interface to a bus [to collect traffic data, event/trace compression and triggering options] • PIN-INTERFACE: OCP interface to the package pins [to transmit real time (in-circuit-emulation) or non-real time (on-chip-analyzer) data to the external analyzer/debugger software]. Support external trigger, boot mode, benchmarking overflow, real-time data exchange. • Debug software outside the chip displays information of the Debug-IP. • API interface to a System Debug software • API interface to EDA - RTL-Verification, simulator, and system level. • Converged EDA -Verification / Software Debug Solutions

7. Bus Direct Register Access Bridge Bus 2 Core Debug IP Core 2 Debug IP 2 Cross Trigger IP Collect Debug Signals CHIP RTL Simulator C++ Simulator Simulink Sim JTAG/Nexus-trace Distribute Transparently Debug Software Debug Software 2 System Debug Software EDA API SYS API SYS API EDA API EDA API Debug Definition: Multi-core System Debug Integration of Point Solutions

8. OCP Interconnect Standardize Interfaces ! Cross Trigger IP Debug IP Debug IP 2 Direct Register Access Core Core 2 External Debug Interface CHIP JTAG/Nexus-trace RTL Simulator C++ Simulator Simulink Sim Distribute Transparently Debug Software Debug Software 2 System Debug Software EDA API SYS API SYS API EDA API EDA API OCP Debug Definition: OCP SoCket Integration of Singular Debug Solutions

9. OCP Debug Interface Specification Overview • Each Debug Feature requires a set of signals in the OCP Interface • OCP statement of need for debug standardization or strategy. • Common set of Debug Guidelines and models • Support range of debug strategies for embedded systems • Common set of guidelines and infrastructure. • Types of debug resources • Minimal set of baseline debug features • Comprehensive set of debug features • Extension to hierarchical debug concepts • Understand approaches that worked well and new capabilities needed • Leverage signals /interfaces defined in OCP 2.0 spec (mainly JTAG) • Definition of signals for other aspects of a debug infrastructure • Facilitate standardized, more uniform, and potentially automated debug procedures

10. Technical Rationale • On-chip debug interface definition makes OCP an "Even More Complete Socket“ for system-IP and debug-IP integration • Provides a common set of debug options and consistent interfaces • Standardized debug = easier to instrument design, improved time to market • Debug options and reuse supports OCP in simulation, emulation and on chip • Robust debug differentiates OCP - more attractive to potential members • Cost reduction: more effective debug component sharing and reuse • EDA • On-chip debug focus complements EDA simulation based debug • More integration between EDA and on chip debug flows = better verification • Better support for OCP based designs with standardized products • Risks • Alternative is everyone going it alone, with many competing debugstrategies • Built-in debug HW minimizes risk

11. Industry Adoption and Risk Reduction Plans • Development needs to be inclusive, not exclusive • First and only Debug-IP integration-solution for system designers • Related industry work and implementations, see appendix A1 • Nexus 5001 Consortium, - IEEE 5001 - active working groupaddressing on-chip debug that OCP-IP can leverage • IJTAG - early stage working group - includes DFM, DFT issues • IEEE 1149/BSDL, 1500/CTL, 1450 - Debug IP and interface descriptions for EDA and Test tools integration • DFD Consortium - new association formed during DAC (FS2, DAFCA are charter members) • Factor in existing company centric debug related activities • Currently available OCP debug IP and tools

12. Proposed Activity and Goals for an OCP-IP Interface • Initial focus on basic debug/analysis functionality : • Run Control - start/stop/halt cores or IP-blocks over an interface • Trace - collect data off-chip or on-chip with global time-stamping and based on a start/stop trigger (with optional data/events compression) • Cross triggering: based on the status of buses, cores and IP-blocks do start/stop data collection or start/stop cores and IP-block execution • Debugger/Analyzer functions should (also) run in FPGA-emulation tools • . • More aggressive nice to have things - maybe beyond our reach • Standardized interfaces between EDA tools and debuggers/analyzers • Standardized Debug migration between prototype (FPGA-emulation) and final-chip environment • Prioritized efforts to be targeted in a "Working Group" is • 1st Priority -The OCP interface to the cores and IP-blocks. • 2nd Priority - The OCP-bus-debug interface for traffic observation and • 3rd Priority - standardize next gen. debug IO (extended JTAG/SerDes)

13. Remarks to OCP Debug Strategy • Enable system integration solutions for debug IP by standardizing important interfaces • Implementation of debug solutions may be done by many debug-IP providers in many different ways. • Keep OCP interface standard close as possible to existing standards • System integrators want to connect the system debug componentsto existing debug solutions without changes to the existing debug hardware and software.

14. Debug Usage and Tools Business Model • Open support for 3rd party models, hardware and software tools, IP, etc. • Focus on use by IP and systems developers and integrators • Advantages • Reduce development required for basic and advanced debug features. • Venders gain readily identified potential market (of OCP members) • Support by participating IP venders • Support by Debug tools and probe developers • OCP members benefit from infrastructure (IP.Probe, SW, venders) • Make Spec openly available • No implementations owned by OCP-IP • IP and tools for sale to the OCP community • No limitations on specific OCP debug architectures, either for internal use or for sale

15. Timelines for Development (WG Deliverables) • Factors to completion • How aggressive a debug solution is being proposed, • Willingness to adopt and leverage solutions already in place • Draft debug specification • Basic set of features in 3 -6 months • More comprehensive debug standard - more options may take severalmore months to resolve • Proof of Demonstration prototype • Prototype RTL implementation for subset of debug features • Probe and basic software support for an OCP debug architecture • 6 months, possibly earlier given committed alpha customer or othersufficient motivation • Reference architecture would be licensable to OCP members

16. Decisions Approval to form an “OCP-IP Debug Interface Working Group” ?

17. Appendix The following part is confidential just for members of the “OCP-IP Debug Interface Study Group”. Do not distribute this appendix beyond group members!

18. Proposals of Group Members A1 • FS2 • DAFCA • CAST/ Evatronix • TI • Toshiba • MIPS • Nokia • other

19. Block Diagrams of Existing Solutions A2 • FS2 • DAFCA • CAST/ Evatronix • TI • Toshiba • MIPS • Nokia • Other (on Internet)

20. Missing Pieces for SoC and in OCP A3 For simpler life in building SoCs we would like to • Extended or new OCP interfacesto address debug instruments and transport of debug information inside the chip and to outside pins. • Support heterogeneous multi-core SoC with common debug interconnect and integration standard. • Standardize not only the debug interface to cores but also the protocol how to use the signals and retrieve debug information. • Standardize API interface from the debug software to a system debug software for heterogeneous multi-core debugging • Propose APIs from debug software to EDA tools (SoC RTL, C++ … simulation) • Address improved integration of advanced debug capabilities • Smooth debugging of IP-blocks that are in sleep mode • Extended error generation that takes debug into consideration

21. Missing Pieces for SoC and in OCP (Cont.) A4 · Debug aware peripheral – HW process stopped when processor acknowledges debug-state has been entered. · Shared peripherals – Suspend line owner handling · Security · Debug HW mapped to separate power domain · Application / Debugger flows separation · Debugger access qualification · Error reporting · Debugger access to target in power down · Improve code download performance through OCP

22. Debug Components A5 • Standardize on debug interfaces supporting higher performance debug/trace • JTAG and JTAG extension port definitions • Multiplexed JTAG chains • Nexus TAP and protocol • Other (futures) - SerDes (Aurora), single/dual wire • Debug interfaces at Socket Level • Coordinated (Multi)Processor run control • Processor OCP trace and performance and analysis interfaces • OCP Bus trace and performance and analysis interfaces • General Logic IP trace and performance and analysis interfaces • Multi-core, systems oriented debug requirements: • Cross triggering, and system level run control for multi-core debug • Time-stamping for coordination of trace and debug information • OCP Debug Wrappers for integrating of pre-existing, proprietary, processor-dependent debug blocks • Reduced JTAG I/F pin count • Synchronous run [simultaneous resume] • Power Management interface • Clock Management interface • Reset Management interface

23. Debug Features A6 · Trace is not limited to OCP bus activity or processor execution · Macroscopic system SW trace [like “printf”] · Messages from application SW through OCP interconnect · Cross-triggering shall include Trace events · Benchmarking – Performance monitoring · OCP interconnect bandwidth optimization · Efficiency of Clock / Power domain gating · Bandwidth versus initiator / Thread / DMA channel · Standardize sequence to wake up debug HW

24. Hierarchical Assembly of Systems and Automatic Debug Extension A7

25. Few Solutions to the Hierarchy-Compatible Debug-IP A9