Debug signal interfaces are outside of the scope of the current OCP 2.2 specification, however the OCP-IP (OCP International Partnership) Steering Committee has recognized that add additional signal interface definitions to support on-chip debug make OCP an "Even More Complete Socket."

On-chip debug addresses the visibility and control needed for improved analysis of operations and interactions within OCP architectures, at different stages in design flows, while providing a common set of debug options and consistent signal interfaces.

OCP Debug definitions also provide a common set of interfaces that allow better support from debug probe and tool venders and EDA tool venders and to enable convergence of debug and verification activities.

The initial goal of the working group is to document a common set of Debug Guidelines and socket level signal models that address the range of simple to more complex debug of OCP based systems.

These include debug configurations and strategies that comprehend multiple clock domains, power management domains, security domains, etc. required in modern SoC and embedded systems design. Conceptually, the architecture avoids the need for a separate debug bus to keep a simple modular on-chip IP (Intellectual Property) structure, in line with the OCP-IP architectural philosophy.

Where possible the debug specification leverages signals and interfaces defined in other OCP specifications. As an example, JTAG signals were defined in OCP2.0 as a primary debug interface, and are therefore referenced as a default option for on-chip debug integration.

The intent however is not to limit implementation to 1149.1 JTAG. Interfaces with higher bandwidth options to enable better debug support are often needed, with some options being Nexus and MIPI interfaces, AJTAG, SerDes (Aurora), other interfaces, etc.

As another option for more directly integrated debug control interfaces, such as memory mapped debug options using an embedded processor for debug block configuration and control are also supported.

OCP Debug Working Group areas of Focus
 There are several other industry working groups that are addressing aspects of DFD and related on chip debug problems. As shown in Figure 1 below, some of the debug related industry activities include:

1) Nexus (IEEE 5001) Forum, which is focused on high performance trace related interfaces based on the IEEE 5001 (Nexus) standard;
2) MIPI Alliance Test and Debug working group whic is addressing a range of debug interface efforts;
3) IJTAG (P1687) , which is a working group looking at JTAG extensions
4) Multicore Association (MCA) which is looking at integrated set of Debug and Communication APIs for Multicore architectures.
5) AJTAG (P1149.7) which is looking at 2 wire JTAG architectures
6) SPIRIT Consortium has a Debug working group looking at debug register description within the SPIRIT IP-XACT frameworks.

Figure 1. Debug Infrastructure Activities

The OCP Debug Difference
The work addressed by the OCP Debug Group complements these other efforts. Specifically we are focused to standardizing a set of OCP debug interfaces to enable new and more rapid application of system debug/observation/cross-triggering IP and software solutions.

One key point that needs to be emphasized is that the other discussed efforts are looking at the debug interface from the chip access or trace protocols at the port and pin level or at addressing related software and modeling requirements.

None are looking at standardizing at the IP socket level interface and its directly adjacent instrumentation and wrappers, which is the primary focus in the OCP-IP working group.

Figure 1above shows one interpretation of the relative areas of focus of some of the different working groups. The OCP Debug working group focus differs from Nexus and MIPI activities by focusing on local debug of IP interfaces and operation standardization at the socket level, i.e. at the core and bus interface level, to address OCP compliant IP or subsystem debug control and visibility.

These interfaces are interoperable with and should not overlap the IO level definitions that are the primary focus for Nexus, MIPI, and others.

Figure 2: Integration of OCP-IP Debug Sockets and Nexus

OCP Debug Overview
In recent years, the Open Core Protocol (OCP) paradigm has become an accepted solution for delivering high-performance on-chip interconnect fabrics for massive multi-core systems-on-chip. A special class of this paradigm is the multi-processor systems-on-chip (MP-SoCs), which are increasingly used in many emerging applications.

The focus of the OCP-IP Debug Working Group is the development of a mechanism for the system wide debug of a heterogeneous MP-SoC using a standardized OCP bus interface for all IP blocks. The standardized bus interface or socket, provides a well defined set of vender neutral signals that address all of interfaces between a core and the bus fabric.

The essence of the proposed debug solution is an optional OCP port, known as the Debug Interface Socket, which may be added to all cores and IP blocks that support or need debugging access.

With the occurrence of multi-core architectures, new requirements for debugging have emerged, related to observing the interacting activities of two (or more) cores in a "co-debugging" or comparative debugging situation. Debug Interface Sockets facilitate such multicore debug since multiple debug points share common debug signal definitions.

The Debug Interface Socket is an OCP port that includes several configurations specifically to support debug interactions. It may communicate off chip via a number of mechanisms; most common being a test port or memory mapped interface to processor.

If debug blocks are memory mapped, then the debug socket may be implemented as part of the OCP Data Socket for simplified interface to other on-chip IP blocks and cores.

Since debug is increasingly a system level problem, the debug interface defines several layers of extended functionality to address the disparate needs of three major debug communities: Software, hardware, and mixed SoC prototyping. One goal is to enable debug companies to offer a library of proven debug IP blocks for a mixture of debug situations and purposes at these different levels.

The Socket IP is ideally supported by a commercial infrastructure of tools, SystemC and other transaction based ESL and virtual debug block models, which complement the emerging trends in SoC design flows, and which interact with other OCP IP to provide comprehensive IP based debug solutions.

In the same way that the OCP data socket provides a superset for different bus interfaces and data structures, the Debug Interface Socket supports a superset of debug solutions, including those developed outside of the OCP-IP membership. As shown in Figure 3, below, the key components of a simple (dual core) SoC Debug environment includes:

Debug Hardware Interfaces
1. Core Interface " interface to core or IP block (ex. Processor run control and debug data /control)

2. Bus Interface " interfaces to a bus socket or fabric (ex. traffic collection, bus event/trace, bus level triggering

3. Cross Trigger Interface "debug block related event synchronization and controlled actions

4. Pin Interface Control " interface to package pins (JTAG for debug control, trace ports for information export to external analyzers.). This differs for various types of interfaces and may outside of the OCP-IP Debug specification

5. Pin Interface Data " other higher speed data/trace interfaces (also defined outside of the OCP-IP Debug specification)

Debug Software Interfaces
A. API interfaces to a System Debug Software tool " allow simpler integration and more System levels debugger software tool features.

B. API interfaces to EDA tools " allow better Verification, Simulator, ESL integration.

Figure 3: Debug environment with five typical SoC hardware connections

The OCP Debugging Framework concepts are extensible and can be reduced to single core debugging without cross-trigger and time-stamping and can be extended to more debug channels by duplicating hardware.

In the context of the needs of multicore architectures, the Debug Interface Socket supports at least dual channel event synchronous debug. Dual channel is a minimum to enable comparison, of event synchronous views of instructions and on-chip events to be displayed with correct temporal relationships.

More extensive approaches are supported by direct extension. Temporal relationships between many channels may be established by several means, time stamping during collection of trace information being a simple and direct approach. To enable coherent, system-wide start and stop of debug tracing and other real time on-chip control, a hardware-light cross-trigger concept is proposed.

Next, in Part 2: How will an OCP debug interface be used?

Neal Stollon is Principal Engineer at HDL Dynamics, an IP company developing on-chip debug solutions. He has previously worked for Texas Instruments, Alcatel, LSI Logic, and MIPS Technologies. He holds a Ph.D in EE from Southern Methodist University and is a Professional Engineer based in Texas.

Bob Uvacek is OCP-IP DWG Chair and Pixelworks senior director, and has design experience and interests in VoIP DSP and chip making, Adaptive Computing Machine (ACM) chip design, rapid algorithm/chip prototyping in real-time with Matlab/Simulink and dSPACE and with the Cell processor.

Reader Response

I enjoyed the article, but there was no definition of IP. I wasn't sure if it was referring to a network-based OCP interface or to intellectual property. It turns out to be the latter, as I learned from the OCP-IP home page (link in first paragraph of article).

-Alex Measday
Software Developer
Lanham, MD