Overview of Debug Standardization Activities

Transcription

1 Silicon Debug and Diagnosis Overview of Debug Standardization Activities Bart Vermeulen NXP Semiconductors Rolf Kühnis Nokia Neal Stollon HDL Dynamics Gary Swoboda Texas Instruments Jeff Rearick AMD Editor s note: The semiconductor industry is disaggregated, with a complex web of suppliers and consumers. Standards help to facilitate and simplify the debug process. This article provides an overview of current standardization activity. Rob Aitken, ARM OVER THE PAST decade, the semiconductor industry has seen a significant increase in the complexity of embedded systems. Multiple heterogeneous processor cores are now on a single die, together with hard-wired accelerators and dedicated or general-purpose I/O peripherals. The code size of the software that runs on these embedded processors is also increasing dramatically. As a consequence, a new combination of embedded hardware and software often must be debugged. Because of the many different components that make up an embedded system, debugging has become a multidisciplinary problem, requiring detailed knowledge of system hardware, embedded software, and debug equipment and tools. Each of these components requires its own expertise, making it vital that all components fit together seamlessly. Well-defined industry standards enable the interoperability between components produced by different parties. Standards provide the basis that producers and consumers rely on to ensure their components will work together with others conformant parts. One area in need of such standardization is that of on-chip debug processes and instruments. The debug area particularly exhibits limited commonality between different IP providers in terms of interfaces and visibility for methods for complex SoCs. The problem becomes even greater with more SoC integrators using diverse IP from different vendors, requiring an increasing range of debug, analysis, and optimization capabilities. These go far beyond traditional debug capabilities because they must provide on-chip increasing first-pass design success by improved prototyping, reducing postsilicon verification and time to market, optimizing hardware and software interfaces and operations, complementing and validating documentation, and providing validation of correct hardware and software functionality through the observation of internal chip events. In recent years, these requirements have led to standardization activities in the debug and diagnosis area that bring together IP core providers, semiconductor manufacturers, and vendors of debug tools. This article describes the goals and ongoing activities of five debug standardization bodies: the Nexus 5001, MIPI (Mobile Industry Processor Interface) Test and Debug, IEEE P1149.7, IEEE P1687, and OCP-IP (Open Core Protocol International Partnership) Debug working groups. We also discuss the relation between these various activities and their standardization plans for the near future /08/$25.00 G 2008 IEEE Copublished by the IEEE CS and the IEEE CASS IEEE Design Test of Computers

2 Debug standardization bodies Figure 1 provides a high-level overview of the relationship between the five working groups, with respect to the onchip core debug interfaces, the device debug interfaces, and debug equipment and tools. At the center of these standardization activities resides the interface traditionally used for test and debug, the IEEE test access port (TAP). Nexus 5001 extends the TAP by defining a message-based interface between on-silicon instrumentation and debug tools for the automotive industry. IEEE P standardizes a successor to the TAP, providing full backward compatibility, while enabling additional capabilities for presentday and future test and debug needs. The MIPI Test and Debug working group leverages the IEEE P interface and adds high bandwidth, unidirectional trace interfaces for smart phones, and other network devices. IEEE P1687 focuses on standardizing the access to on-chip instruments via the existing TAP. The OCP-IP Debug working group focuses on standardizing the critical set of on-chip debug functions and how they interface to system-level debug and analysis tools. The groups joint goal is to standardize the debug interfaces between different IP cores on a chip as well as between different chips and the external debug equipment and tools. Standardizing the debug interfaces between these components can save a significant amount of debug time and resources, which can then be put to better use on the actual debugging of system problems. Debug standardization is essential to allowing onchip debug instruments, chips, and external debug and analysis tools to be quickly connected together to form a working debug setup. The standardization efforts currently ongoing in the Nexus 5001, MIPI Test and Debug, IEEE P1149.7, IEEE P1687, and OCP-IP Debug working groups constitute an important first step toward reliable component interoperability. Figure 1. Focus areas for the groups working on debug standardization. Nexus 5001 The Nexus 5001 Forum is an industry-based standards group that manages the IEEE 5001 (Nexus) Debug Specification. 1 The Nexus activity was initiated in 1999 as an extended and inclusive specification based on the Global Embedded Processor Interface Forum s work. It addresses the need for a standardized interface for on-silicon instrumentation and debug tools that allows expanded features and higher performance. The specification s current version was released in Since then, versions of Nexus architectures have been used extensively in US automotive applications. The Nexus architecture defines an open, highperformance debug data interface, associated protocol, and register infrastructure (see Figure 2) that can serve to implement various trace and control instrumentation. The Nexus interface defines a small set of control signals and auxiliary data ports for use in conjunction with an IEEE TAP or as a selfcontained port. The additional data pins provided by the auxiliary interfaces allow much higher instrument throughput compared to the IEEE TAP. Recognizing that various applications have differing debug requirements, Nexus defines functionality and compatibility over four classes of operation: Class 1 provides basic debug features common with most processor and IEEE debug May/June

3 Silicon Debug and Diagnosis Figure 2. Nexus 5001 interface. (TAP: test access port.) 260 implementations, including device identification, single stepping, breakpoints and watch points, and access to static memory and I/Os. Class 2 provides features related to processor execution trace, including real-time monitoring of process ownership and instruction tracing, along with complex watch points and branch tracking, which flags indirect branches and eliminates redundant addressing information. Class 3 provides support for data, memory, and I/O read/write instruction traces while the processor is running. Class 4 provides a user with direct control over the processor for example, by letting programs be executed from the Nexus port (memory substitution), along with features for remapping memory and I/O ports, and by starting a trace upon a watch-point occurrence. Device instrumentation and tools are class 1 through 4 compliant if they support all the features defined in each class. Higher classes progressively increase the ability to debug the chip-level system and analyze more complex processor operations, but they involve more instrument and system complexity. Each auxiliary interface is unidirectional (either data in or data out) with its own clock. An auxiliary interface s data-out pins are typically used for trace, and the data-in pins are for a chip s configuration and calibration. Auxiliary data in and out ports may be operated concurrently. The Nexus specification also describes how to use an IEEE TAP in conjunction with the auxiliary ports. IEEE operations in Nexus can be used for configuration and control of the onsilicon instrumentation as well as for embedding the Nexus protocol and data into an IEEE message. Both auxiliary and IEEE interfaces are controlled by a set of finitestate machines (FSMs) that allow various transfer operations. The Nexus architecture design is based on a packetbased messaging scheme, and it uses a transaction protocol that supports debugging complex multicore systems and controlling multicore debug processes (see Figure 3). Data is sent in packets, and packet headers provide information on the data s source and destination, along with information on whether the associated data packets contain trace data or other information. This simplifies the interleaving of data from multiple trace sources and the concurrent communication with multiple Nexus instruments. The Nexus specification defines a standard set of transaction protocols for common identification and trace operations. The transaction protocol can be extended with user-defined debug commands. The Nexus specification also defines a standard set of on-chip debug registers, which facilitate the identification and which interface to different cores and subsystems. The specification also supports control over multicore debug operations. A standard register set allows simpler integration and control of the on-chip instruments by external debuggers and analysis tools. MIPI Test and Debug The MIPI Alliance is primarily focused on smart phones and other portable, application-rich networked devices, or mobile terminals. The unique requirements of mobile terminal systems drive the development of all MIPI specifications. These specifi- IEEE Design Test of Computers

4 cations address only hardware and software interface technology, such as signaling characteristics and protocols, and do not standardize entire application processors or peripherals. In 2004, MIPI formed the Test and Debug (MIPI TD) working group. Recognizing the need for a standard that addresses the increasing number of interface requirements for test and debug that the IEEE standard does not cover, the MIPI TD working group developed a specification that was reviewed both inside the working group and within the Nexus 5001 standardization body in late Both recommended using the on-chip portions of this specification as the basis for a new IEEE P standard. Since then, the MIPI TD working group has addressed other system-level issues (see Figure 4). The MIPI TD working group has defined two standards and one recommendation related to application debug on mobile terminals: Figure 3. Nexus 5001 architecture. (FSM: finite-state machine.) This interface uses dual-data rate, has a configurable export port width, and outputs the clock and data 90 degrees out of phase from each other. The MIPI TD Debug Connector recommendation covers a range of capabilities from basic debug connectivity (as little as 10 pins) up to high-speed parallel trace (60 pins). Two white papers are available as well: The System Trace Protocol (STP) specification standardizes a highly optimized protocol used for encoding instrumentation trace information (hardware or software generated). It automatically adds time-stamp information to the exported messages. The Parallel Trace Interface (PTI) specification standardizes a high-bandwidth interface for transferring debug and analysis data from a target system to an external debugger. Figure 4. Working areas of Mobile Industry Processor Interface Test and Debug (MIPI TD) working group. (M-PHY: MIPI high-speed serial, physical communication layer; STP: System Trace Protocol.) May/June

5 Silicon Debug and Diagnosis The MIPI Test and Debug Interface Framework white paper explains the components of a MIPI test and debug system. 2 The MIPI Alliance Test and Debug - NIDnT-Port (Narrow Interface for Debug and Test) white paper describes how software and silicon debug can be done on an assembled mobile terminal. 3 Currently, the group is working on the following topics: An STP extension will help create a multidrop STP. The goal is to have only one trace port in an assembled terminal, connected to several SoCs. One of the topics is how to achieve this goal with minimal hardware infrastructure. The Open System Trace Protocol provides standard APIs and protocols to enable software tracing tools to work seamlessly with different SoCs implementing the MIPI STP. The group will also explore instrumentation protocols that can be used with the upcoming IEEE P standard. Already, other standardization working groups are active in the area of high-speed serial trace (gigabit trace). However, most of the proposed physical layers are unsuitable for mobile terminals due to their area cost and power consumption. Therefore, the working group is looking into different possibilities to replace existing parallel trace solutions with a high-speed, low-voltage, differential-signaling trace interface. IEEE P The IEEE P working group started in March Its Draft Standard for Reduced-Pin and Enhanced- Functionality Test Access Port and Boundary Scan Architecture is meant to be a successor to the popular IEEE standard. It is fully backwardcompatible, while adding capabilities that support both present and future test and debug needs. Through this compatibility, any IC using the IEEE interface can use the IEEE P standard to reduce the pin count of its test interface to two pins. To enable this, IEEE P introduces an additional control layer between the on-chip IEEE TAP controllers and the device s TAP. This layer preserves all elements of the IEEE interface at the device level, while also providing options for introducing new functionality and features. The key aspects of the IEEE P standard include use of multiple TAP controllers on chip, support for commonly used debug capabilities, operation with four TAP pins in a four-pin star scan topology, operation with two TAP pins in a two-pin star scan topology, concurrent use of the chip TAP for scan and instrumentation of an application, use of the TAP for private protocols in a manner compatible with normal operation, and power down and power up of test logic on demand of external debug and test equipment. The IEEE P standard makes it possible to create IEEE P TAPs with six capability classes (T0 through T5), all sharing common characteristics (see Figure 5): Class T0 is fully IEEE compliant and provides interoperability for multiple on-chip IEEE TAP controllers. Class T1 provides additional debug functions and features to minimize power consumption. Class T2 adds IEEE compatible operating modes to maximize debug, and optional features to improve scan performance. It also provides a hot-connection capability to prevent system corruption. Class T3 enables the operation of four-pin TAPs in a star configuration. Class T4 provides debug and test communication using either a two-pin (narrow) or four-pin (wide) interface and adds a number of options to improve scan performance. The IEEE protocol is used to stimulate either of the interfaces from power up, whereas an advanced two-pin protocol is used when only two pins are involved in interface transactions. An option to begin operation with the advanced protocol is also provided. The advanced protocol serializes standard IEEE transactions to allow pin reuse and higher interface clock rates than those afforded by the IEEE standard. Class T5 adds the capability to perform data transfers concurrent with scan, supports use of functions other than scan, and provides control of the TAP pins to custom debug technologies in 262 IEEE Design Test of Computers

6 a manner that ensures current and future interoperability. Each higher class includes all capabilities of the underlying classes. IEEE P can be combined with the efforts of other standardization bodies that use the IEEE standard as their basis, such as the Nexus 5001, MIPI TD, IEEE P1687, and OCP-IP debug activities. IEEE P1687 (IJTAG) The semiconductor industry is in the midst of an explosion in the use of onchip measurement circuitry to provide insight into the operation of increasingly complex devices. A typical SoC today is equipped with triggered trace capture buffers for logic analysis, temperature monitors for thermal management, bit-error ratio testers for high-speed serial I/O link testing, memory and logic BIST for defect detection, and many other embedded instruments. This proliferation of instruments is growing, but it has not yet been accompanied by a method to facilitate use, reuse, interoperation, and automation; this is where the emerging IEEE P1687 standard adds value. 5 The IEEE P1687 working group focuses on the standardization of the access to on-chip instruments, but not of the instruments themselves. Given the widespread adoption of the IEEE TAP and its associated controller, IEEE P1687 explicitly uses this TAP as its primary external interface to embedded instruments. Its informal name, IJTAG (Internal Joint Test Access Group), reflects this legacy. The primary objective is to provide a standard mechanism to interact with on-chip instruments through a TAP. This standard mechanism can be decomposed into hardware and software elements. The hardware element refers to the specification of the on-chip interface between the TAP and the instruments and is flexible so as not to overconstrain the instruments architecture. Figure 6 outlines the P1687 hardware Figure 5. IEEE P classes and functionality. interface s context, which consists of one or more scan gateways registers similar to an IEEE test data register (TDR) between the TAP and the instruments. The gateways separate the IEEE zone from the IEEE P1687 zone. IEEE instruction-register actions select a gateway TDR, after which data-register scan operations through the gateway interact with the instruments. The minimum set of signals in this interface consists of an instrument enable (or select) signal and the traditional capture, shift, and update signals that a TAP controller produces. The software element consists of three components, all of which can be viewed as description languages: A hardware description language (HDL) specifies the connectivity of the instruments to the TAP (via register names, signal names, scan path, and bit position information in a format likely to be a straightforward extension of IEEE BSDL). A pattern/procedure/protocol description language (PDL) describes the instrument s operation at the instrument boundary and internal register level; and An API allows abstraction of the instrument functions and codification of instrument actions into a library. May/June

7 Silicon Debug and Diagnosis Figure 6. IEEE P1687 architecture. (BSDL: Boundary Scan Description Language; DR: data register; IR: instruction register; TCK: test clock; TDI: test data input; TMS: test mode select; TRST: test reset (active low); WSI: wrapper serial input; WSO: wrapper serial output.) TheIEEEP1687usemodelisasfollows: 1. A provider creates an implementation of an instrument, along with its HDL and PDL descriptions. The HDL identifies the instrument s registers and ports. The PDL describes the actions that the instrument can perform (written in terms of those registers and ports). 2. A chip integrator incorporates this instrument into a chip design and creates a top-level HDL, taking the global scan connectivity into account. 3. Using this top-level HDL and an EDA tool, the integrator retargets the instrument s PDL to the chip level. 4. Users construct test and debug programs in their favorite language using the API, without dealing with low-level details. More than 20 members of the IJTAG working group have met weekly for the past two years. The extended mailing list includes hundreds of others, representing a wide cross section of the industry. The standard s hardware interface specification has been completed, and three subteams are currently busily working on the respective language specifications. OCP-IP Debug The OCP-IP ( is an industry-based standardization group that defines vender-neutral socket interfaces to interconnect processor cores with other on-chip components. The OCP-IP socket-based integration strategy has been proven in a multitude of designs over the past six years. OCP-IP formed its Debug working group in late 2005 to investigate and propose on-chip analysis solutions. This working group initially focused on three areas that were generally considered critical to having an onchip debug solution (which a white paper discusses in more detail 6 ): 264 IEEE Design Test of Computers

8 Figure 7. Debug blocks using both JTAG (Joint Test Action Group) and memory-mapped interfaces. (RISC: reducedinstruction-set computing.) First, define a critical set of debug functions that can be implemented on-chip. These include global run control signals as well as trace, triggering, time stamping, and other on-chip analysis functions. These functions must support modern SoCs that incorporate, among others, asynchronous clock domains, diverse voltage islands, various power-saving schemes, and varying levels of embedded security. They are accessed using an IEEE TAP, dedicated debug access ports, or memory-mapped registers that are accessible from the embedded processors (see Figure 7). Second, define both critical and optional sets of debug signals that allow different IP blocks to communicate and coordinate their specific debug requirements and features. The critical signals are typically common to all IP blocks and are accessed through a common TAP chain or debug port. The optional signal-support functions can be specific to particular blocks or subsystems. Third, define common tools and system-level interfaces and schemas that support more commonality and integration between presilicon and on-chip analysis. Working with the OCP-IP System Modeling working group, define common requirements and evaluate approaches to define common debug inputs (suchastriggersandbreakpoints)aswellascommon software, API, and tool database requirements between different vendors (see Figure 8). The OCP-IP Debug working group s key consideration has been to adopt successful and best-in-class debug components and to leverage compatible work from other parts of the debug and analysis community. As an example, the debug functions and signal interfaces defined are typically at a deeply embedded level, at the core and bus fabric and interface levels, where specific functional and performance information that is critical to debug is equally difficult to access in hardware. The interfaces between these embedded subsystems and the outside world are defined through standardized interfaces, most notably IEEE and IEEE 5001 Nexus interfaces (see Figure 1), both of which are managed by other industry working groups. Combining innovation, pushing current capabilities where required, and leveraging existing solutions where possible allows for evolution of debug solutions that can be rapidly deployed and that appeal to the varied interests of the OCP-IP community. EXCITING TIMES ARE AHEAD for debug standardization, as first results are becoming available on the market and more convergence is expected to take place in the near future. The IEEE P standard is currently May/June

9 Silicon Debug and Diagnosis Figure 8. Integration of on-chip instrument and electronic system-level (ESL) debug strategies. under review and is scheduled for ballot in First chipsets and boards with MIPI-standardized test and debug interfaces and recommended connectors are expected to become available soon. The Nexus 5001 Forum is already collaborating with other debug standardization efforts, including MIPI and OCP-IP. Moreover, it is in the process of extending its Nexus 5001 specification to support emerging debug interfaces such as serializers/deserializers and the two-pin IEEE P TAP. The Nexus 5001 Forum and OCP-IP have implemented a collaboration agreement to manage the standardization effort of the Nexus 5001 specification and to allow a more open and detailed technical exchange. 7 References 1. The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface, v2.0, Nexus 5001 Forum, 2003; pdf. 2. MIPI Test and Debug Interface Framework, v3.2, white paper, MIPI Test and Debug Working Group, Apr. 2006; 3. MIPI Alliance Test and Debug - NIDnT-Port, v1.0, white paper, MIPI Test and Debug Working Group, Jan. 2007; pdf. 4. IEEE P1149.7, Draft Standard for Reduced-Pin and Enhanced-Functionality Test Access Port and Boundary Scan Architecture, IEEE, 2008; groups/1149/7. 5. IEEE P1687 IJTAG, Draft Standard for Access and Control of Instrumentation Embedded within a Semiconductor Device, IEEE, 2008; grouper.ieee.org/groups/1687/index.html. 6. N. Stollon, B. Uvacek, and B. Laurenti, Standard Debug Interface Socket Requirements for OCP-Compliant SoC, white paper, OCPIP Debug Working Group, Mar. 2007; 7. OCP-IP and NEXUS Announce Collaboration on Industry Standard Debug Efforts, press release, OCP-IP and Nexus 5001 Forum, Aug. 2007; releases/2007_press_releases/ocp_nexus.pdf. The biography of Bart Vermeulen appears on p. 215 of this issue. Rolf Kühnis is a technology manager at Nokia. His research interests include debug and trace technologies for the development of wireless hand sets. He has an MSc in electrical engineering from ETH Zurich. 266 IEEE Design Test of Computers

10 Jeff Rearick is an AMD Fellow and leads AMD s Design for Testability Center of Expertise. His research interests include a range of DFT strategies for leading-edge microprocessors from memory and logic BIST to small delay defect ATPG, to embedded instrumentation for highspeed serial I/O circuits. He has a BS from Purdue University and an MS from the University of Illinois at Urbana-Champaign, both in electrical engineering. Neal Stollon is a principal engineer at HDL Dynamics, an SoC IP consulting and service provider. His research interests include SoC instrumentation and ESL-based debug tools development. He has a PhD in electrical engineering from Southern Methodist University. He is a senior member of the IEEE and a registered Texas professional engineer. Gary Swoboda is a Texas Instruments Fellow. His research interests include defining TI s debug technology infrastructure, helping define TI s overall development tools roadmaps, and influencing the definition of new DSP architectures. He has a BS in electrical engineering from the University of Texas at Austin. Direct questions and comments about this article to Bart Vermeulen, NXP Semiconductors, High Tech Campus 37, Room 2.52, 5656 AE Eindhoven, the Netherlands; bart.vermeulen@nxp.com. For further information on this or any other computing topic, please visit our Digital Library at computer.org/csdl. May/June