As discussed in Part 1 in this series, in the same way the OCP data socket is a superset for the different bus interfaces and data structures, an OCP debug socket will provide a superset of the debug solutions based on standardized libraries of debug IP blocks that interact with the debug sockets signals. This allows the following:

1) Signal level observation (bus and system trace) and control (triggering)
2) Consistent (multiple) processor software debugger and bus traffic observation interfaces
3) Special debug features for security islands, voltage islands, gated clock islands etc.
4) New classes of debug errors (which are different from system errors.

Three views of debugging
So, how will the new debug environment be applied by OCP-IP users? Motivations and requirements for on-chip debug can differ widely between companies, projects, and points in the design cycle. At least three variants need to be satisfied by a standard:

Hardware Centric Debugging. which concentrates on additional IP blocks in hardware to expose chip internal signals and registers to prove correct internal functionality or correct design parameters at the pins (via JTAG or other methods) This may include observation of signals from diverse parts of the SoC, including signals inside IP cores.

Triggering and trace capture need to be precise to a clock cycle, for analysis and to correlate debug hardware to simulation based verification. Depending on the architectures, software debuggers may not be required; however if they are, including instruction execution information for processor architectures is often needed for analysis of interacting operations such as processor loads and stores

Software Centric Debugging. Software debugging concentrates on minimum additions in hardware to provide a debug environment for software analysis (under the assumption that the hardware is implemented correctly). Many processors include a software centric debug capability (MIPS EJTAG, ARM ETM as examples).

In most cases, the debugger connects to the processor(s) to provide processor run control (and breakpoints) or execution trace. Alternately, a processor may be used as a debug controller, with special instructions and triggering signals to coordinate other on-chip debug activities.

System on Chip Debugging. System on Chip debugging merges the common software tracing and hardware observation requirements for SoC analysis. In many multicore applications, observation of the on-chip hardware interactions and comparative debugging of two or more cores is essential to complete verification of the software application. A System oriented debugging approach also must include other key features for modern SoC architectures

* The OCP debug definitions are independent of the target hardware and allow capture both "pre-reset" and "post-crash" events as well as bus traffic bottlenecks.

* Debugging is configured to proceed even if the major parts of the system are in power down or a core is in sleep mode. The debug hardware should be able to be disabled during normal chip operation, for security or power improvement. This may be done either under software control or (permanently) by making parts of the debug hardware inoperable by burning fuses

* Debug features should support more traditional EDA system level verification and analysis of OCP based systems. Where possible, RTL or other block models should be available for EDA analysis for JTAG and DFT, BIST, and other debug structures, even when these are implemented as physical (post synthesis gate level insertion) macros.

* From a system point of view, debug blocks should provide the system level (System-C) model abstractions used in other areas of a design, in order to support ESL simulators and high level software debuggers. This simplifies interaction of the hardware and software personnel being involved in the debug process.

Figure 4 " OCP Multi-core Interfaces Including Debug and Data Sockets

Defining the right signal groups
Keeping these various interests in mind, the OCP IP Debug Working Group has defined signal groups required to enable a multicore-optimized OCP debug interface socket that, in many multicore analysis scenarios, provide synchronized debug control, debugger interfaces, cross-triggering interfaces, etc.

Also defined are also a number of optional (extended) groups based on specific debug and analysis requirements. These optional/Extended Debug Signals define debug features such as time stamps performance analysis. They also define specific "debugging aware" functionality for SoC designs that have security domains or power management with voltage islands.

Debug Components and IP Interfaces. The basic signals for an OCP Debug Interface Socket may be added to all cores and IP blocks that support or need debugging access. OCP debug ports sockets may be implemented independent of data sockets, including at different points in the OCP system from where a Data port may be implemented.

The OCP Debug socket may be implemented as additional signals to the OCP Data (master and/or slave) port (for debug blocks are memory mapped and controlled through the OCP Data socket) or as an independent OCP port configuration which can be controlled via JTAG or other external interface.

Figure 5 " Single-core Debug Solution with Wiring through OCP-Debug Sockets

Figure 5 above shows a simple system where debug IP blocks are implemented and integrated into a modular OCP system interconnect structure that is created from library IP blocks around a bus fabric (as described in the SPIRIT XML conceptual framework). Debug signals go through the system bus fabric and is contacted through an OCP debug port.

In general, while debug socket functions are passive and not intrusive to system operations or performance, some debug related operations (cross triggering, etc.) may have interaction with other parts of the system operation

Debug Interface Definitions. The programming of registers that contain either configuration or status information in the debug IP blocks may be JTAG-mapped or Memory-mapped. Either one or both modes of control and access are acceptable, based on specific system requirements as shown in Figure 6, below.

For simplicity, debug ports reference JTAG and Nexus interfaces, as these are IEEE standards. This restriction is to simplify the interface discussion, and is not intended to preclude integration with MIPI, IJTAG, or other interfaces.

Figure 6. A multi-core debug socket implementation

Basic Socket Level Debug Interfaces. Processor run control is typically implemented via the JTAG interface using debug mode signals in an IP. JTAG interfaces are supported in current OCP specifications with JTAG signals decoded at one or more JTAG TAPs (Test Access Points).

A JTAG-only debug interface addresses many non-real time debug operations, interfacing to debug components on different cores and to set up and synchronize an OCP system into a debug mode. Even in the case of "memory mapped" debug blocks the processor control can operate over this JTAG port.

As a lower speed serial interface however, JTAG does limit data intensive debug operations such as trace, which is required in higher performance test and debug interface efforts.

Higher performance debug architectures may include independent reset and independent clock signals for the debug system synchronized to the debugger interface. An independent clock allows more flexible support of asynchronous or clock gated systems.

An independent reset allows analysis of the target during system reset sequences. Additional reset and clock signals for time stamping counters may be common or independent from debug control interface.

Core (Master) Debug Socket Interfaces. OCP debug programming models should allow user defined debug configurations based on the debug scenario and allow bi-directional debugger accesses to be consistently controlled via these debug interface signals.

Signals defined in the OCP-IP debug environment include debugger initiated debug mode request (rd/wr) and core acknowledge signals to the debugger to communicate a core is in a debug state.

Since debug operations may interact with "normal" system operations, debug interfaces should also support unlocking of stuck-at situations and forcing completion of locked actions (Force, abort, suspend) for a core in debug status OCP peripherals interfaces would also need to be "debug aware", to recognize and synchronize with processor cores or other bus masters that enter debug mode.

Peripheral (Slave) Debug Socket interfaces. A peripheral debug interface should insure that, for Debugger OCP transactions, any debugger initiated debug mode operation reads peripheral information transparently, while preserving the system state.

Depending on debug scenarios and the relationship between the local hardware process and the software process, peripherals should monitor the debug state and may need to take several actions to synchronize with the debug processor and allow Processing of OCP transactions initiated by debugger to be handled differently than those initiated by the application software:

1. Freeze local hardware processes when the controlling OCP Master is in debug state. This may be by a parameter passed into a system debug register via JTAG or under software control or it may be implemented as part of the debug hardware

2. Stop peripheral or other local hardware process when a processor enters the debug state. This can get complicated, since the peripheral may be potentially shared or accessed by several OCP masters in the architecture.

3. comprehend specific updating to ongoing local hardware processes when a OCP master enters a debug state, as an example, disabling application driven peripheral operations (ex. flag clear, post-increment, state machine updates, etc.).

To accommodate the diverse debug scenarios, a peripheral debug programming model may implement the two or more debug control parameters in a system debug register as:

- FREE, which allows keeping the local hardware process free running or make it sensitive to the debugger input.
- SOFT, which allows waiting for a clean boundary before stopping the local hardware process when extra latency is acceptable.

Cross Triggering Socket Interfaces. Cross triggering and their associated system level control are important for debug of complex SoC. Cross triggering allows global and distributed event recognition and multi-core triggering to identify and isolate events occurring throughout the system.

Event recognition and triggering is widely used in conjunction with trace to capture information on on-chip events and data in the SoC. Triggering conditions are monitored and compared to generate real time triggers in a Cross-trigger Manager. Shown in Figure 7 below is a cross trigger with two "trigger lines looped back through the trigger manager.

Depending on the system configuration, signals may need to be preprocessed to allow conditions from different parts of the system to be synchronized or to support cross-triggering from external devices or external signals.

Figure 7. Cross-triggering in the OCP-bus

Complex trigger implementations can be programmed to trigger on specific values or sequences such as sequential combinations of bus address region and data read or write cycle type accesses.

Examples of triggering signals might be debug or interrupt request conditions, although they can include any on-chip signal. Combinations of these triggers in turn can be used to control on-chip actions such as core configuration changes, setting breakpoints or interrupts, initiating trace collection or other user defined requests.

The cross-trigger operation may be distributed among different IP connections to improve performance and support clock conversion and synchronization. Trigger-in (condition) and Trigger-out (action) pre/post-processing wrappers at each OCP interface point may be configurable (via JTAG or processor control) to simplify the cross-triggering.

OCP Synchronized Run Control. Synchronized Run Control supports clock synchronized program execution of two cores that would run asynchronously in normal case. That makes it possible to time align the instruction streams to study interdependency.

OCP Traffic Monitoring and Trace Interfaces. Traffic monitoring and trace is often a critical debug feature to able to analyze on chip behavior. System monitoring and trace can be done at signals on the data socket or in the bus fabric itself.

Trace requirements are application dependent, requiring signals and monitoring bus traffic events that may be extracted from the system cross-trigger information or provided by a processor or other on-chip IP. Trace should be non-invasive (not affect OCP system behavior) and should be secure (not allowing unauthorized people to snoop into the system). Useful features for Bus Monitoring and trace may include:

1) Continuous (or at least long duration) system monitoring
2) Filtering based on OCP operations (ex. Initiator, thread, address range, DMA logical channel)
3) Trace capture of both OCP transactions and non-OCP qualifying events
4) Transaction filtering and alignment of requests and responses
5) Elastic trace bandwidth at OCP System traffic peaks
6) Support for SW instrumentation interleaving with the trace flow
7) Support interleaving several trace flows from different trace points or channels
8) Support Multi-threaded data observation including system trace data reads from the JTAG or from application SW Since trace is data intensive, high performance interfaces may be required.

Trace-packet interfaces are defined in several protocols, including Nexus (IEEE 5001) and MIPI. Since there are other standards bodies addressing these issues of higher performance debug interfaces, OCP Debug leaves this level of interface open to user's choice.

`Extended (Optional) Debug Interfaces
Additional extended debug signals are needed to support application specific or optional functionality for a targeted on-chip system. These include debug of systems with Power Islands or Secure subsystems (which may be implemented in a variety of ways in different designs). As with other debug signals , communication is anticipated to handled via on-chip debug blocks controlled and configured via JTAG or memory-mapped register communications

Future Directions
Advanced debug techniques and Design for Debug methodologies for complex SoC are still emerging and evolving. There are several organizations looking at the problem from different facets, all of which provide a needed piece of the puzzle.

In the OCP-IP Debug Working group, we are addressing the facet that ties debug of OCP compliant IP bocks in a standardized manner to other activities. This does not result in a solution for SoC debug by itself, but facilitates development of comprehensive debug solutions in conjunction with IP and tool vendors. We expect that progress in developing these debug solutions will require increased interaction with other debug related activities.

A key advantage that the OCP socket architecture provides is a standardized and robust set of interfaces that reduce the risk to IP venders and users in developing interoperable IP and the system developer in applying that IP into systems.The addition of Debug Interface Sockets addresses this emerging issue of enabling complex on-chip debug and how the integrated approaches can be applied to current and future SoC designs.

To read Part 1, go to "The goals of OCP Debug Working Group."

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.

Gilbert Laurenti is a designer with the Texas Instruments Wireless Business Unit, focused on SOC debug architectures on the OMAP platforms.