Defining standard Debug Interface Socket requirements for OCP-Compliant multicore SoCs: Part 1 - Embedded.com

Defining standard Debug Interface Socket requirements for OCP-Compliant multicore SoCs: Part 1

Enabling a robust on-chip debug capability is being recognized as animportant Design for Debug (DFD) capability for complex SoC and having DFDstandardization makes the Open Core Protocol (OCP) moreattractive as a SoC platform.

Debug signal interfaces are outside of the scope of the current OCP2.2 specification, however the OCP-IP (OCP International Partnership) Steering Committee has recognizedthat add additional signal interface definitions to support on-chipdebug make OCP an “Even More Complete Socket.”

On-chip debug addresses the visibility and control needed forimproved analysis of operations and interactions within OCParchitectures, at different stages in design flows, while providing acommon set of debug options and consistent signal interfaces.

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

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

These include debug configurations and strategies that comprehendmultiple 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 asimple modular on-chip IP (Intellectual Property) structure, in line with the OCP-IParchitectural philosophy.

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

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

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

OCP Debug Working Group areas ofFocus
 There are several other industry working groups that areaddressing aspects of DFD and related on chip debug problems. As shownin Figure 1 below , some of thedebug related industry activities include:

1) Nexus (IEEE 5001) Forum, which is focused on high performance trace related interfaces based onthe IEEE 5001 (Nexus) standard;
2) MIPI AllianceTest and Debug working group whic is addressing a range ofdebug 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 andCommunication APIs for Multicore architectures.
5) AJTAG (P1149.7) which is lookingat 2 wire JTAG architectures
6) SPIRIT Consortium has a Debugworking group looking at debug register description within the SPIRITIP-XACT frameworks.

Figure1. Debug Infrastructure Activities

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

One key point that needs to be emphasized is that the otherdiscussed efforts are looking at the debug interface from the chipaccess or trace protocols at the port and pin level or at addressingrelated software and modeling requirements.

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

Figure 1above shows oneinterpretation of the relative areas of focus of some of the differentworking groups. The OCP Debug working group focus differs from Nexusand MIPI activities by focusing on local debug of IP interfaces andoperation standardization at the socket level, i.e. at the core and businterface level, to address OCP compliant IP or subsystem debug controland visibility.

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

Figure2: Integration of OCP-IP Debug Sockets and Nexus

OCP Debug Overview
In recent years, the Open Core Protocol (OCP) paradigm has become anaccepted solution for delivering high-performance on-chip interconnectfabrics for massive multi-core systems-on-chip. Aspecial class of thisparadigm is the multi-processo r systems-on-chip (MP-SoCs) , whichareincreasingly used in many emerging applications.

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

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

With the occurrence of multi-core architectures, new requirementsfor debugging have emerged, related to observing the interactingactivities of two (or more) cores in a “co-debugging” or comparativedebugging situation. Debug Interface Sockets facilitate such multicoredebug since multiple debug points share common debug signaldefinitions.

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

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

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

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

In the same way that the OCP data socket provides a superset fordifferent bus interfaces and data structures, the Debug InterfaceSocket supports a superset of debug solutions, including thosedeveloped outside of the OCP-IP membership. As shown in Figure 3, below, the key componentsof a simple (dual core) SoC Debugenvironment includes:

DebugHardware Interfaces
1. Core Interface ” interfaceto 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, busevent/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 forinformation export to external analyzers.). This differs for varioustypes 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 theOCP-IP Debug specification)

DebugSoftware Interfaces
A. API interfaces to a System DebugSoftware tool ” allow simpler integration and more Systemlevels debugger software tool features.

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

Figure3: Debug environment with five typical SoC hardware connections

The OCP Debugging Framework concepts are extensible and can bereduced to single core debugging without cross-trigger andtime-stamping and can be extended to more debug channels by duplicatinghardware.

In the context of the needs of multicore architectures, the DebugInterface Socket supports at least dual channel event synchronousdebug. Dual channel is a minimum to enable comparison, of eventsynchronous views of instructions and on-chip events to be displayedwith correct temporal relationships.

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

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

Neal Stollon is Principal Engineerat HDL Dynamics, an IP companydeveloping on-chip debug solutions. He has previously worked for TexasInstruments, Alcatel, LSI Logic, and MIPS Technologies. He holds a Ph.Din EE from Southern Methodist University and is a Professional Engineerbased in Texas.

Bob Uvacek is OCP-IP DWG Chair and Pixelworkssenior director, and has design experience and interests in VoIP DSPand chip making, Adaptive Computing Machine (ACM) chip design, rapidalgorithm/chip prototyping in real-time with Matlab/Simulink and dSPACEand with the Cell processor.

Gilbert Laurenti is a designer withthe Texas Instruments WirelessBusiness Unit, focused on SOC debug architectures on the OMAPplatforms.

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


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.