Defining standard Debug Interface Socket requirements for OCP-compliant multicore SoCs: Part 2 -

Defining standard Debug Interface Socket requirements for OCP-compliant multicore SoCs: Part 2

As discussed in Part1 inthis series, in the same way the OCP data socket is a superset for thedifferent bus interfaces and data structures, an OCP debug socket willprovide a superset of the debug solutions based on standardizedlibraries of debug IP blocks that interact with the debug socketssignals. 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 forsecurity 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 widelybetween companies, projects, and points in the design cycle. At leastthree variants need to be satisfied by a standard:

HardwareCentric Debugging. which concentrates on additional IP blocksin hardware to expose chip internal signals and registers to provecorrect internal functionality or correct design parameters at the pins(via JTAG or other methods) This may include observation of signalsfrom 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 basedverification. Depending on the architectures, software debuggers maynot be required; however if they are, including instruction executioninformation for processor architectures is often needed for analysis ofinteracting operations such as processor loads and stores

SoftwareCentric Debugging. Software debugging concentrates on minimumadditions in hardware to provide a debug environment for softwareanalysis (under the assumption that the hardware is implementedcorrectly). 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 provideprocessor run control (and breakpoints) or execution trace.Alternately, a processor may be used as a debug controller, withspecial instructions and triggering signals to coordinate other on-chipdebug activities.

System on ChipDebugging. System on Chip debugging merges the common softwaretracing and hardware observation requirements for SoC analysis. In manymulticore applications, observation of the on-chip hardwareinteractions and comparative debugging of two or more cores isessential to complete verification of the software application. ASystem oriented debugging approach also must include other key featuresfor modern SoC architectures

* The OCP debug definitions are independent of the target hardwareand allow capture both “pre-reset” and “post-crash” events as well asbus traffic bottlenecks.

* Debugging is configured to proceed even if the major parts of thesystem are in power down or a core is in sleep mode. The debug hardwareshould be able to be disabled during normal chip operation, forsecurity or power improvement. This may be done either under softwarecontrol or (permanently) by making parts of the debug hardwareinoperable by burning fuses

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

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

Figure4 ” 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 Grouphas defined signal groups required to enable a multicore-optimized OCPdebug 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 basedon specific debug and analysis requirements. These optional/ExtendedDebug Signals define debug features such as time stamps performanceanalysis. They also define specific “debugging aware” functionality forSoC designs that have security domains or power management with voltageislands.

DebugComponents and IP Interfaces. The basic signals for an OCP DebugInterface Socket may be added to all cores and IP blocks that supportor need debugging access. OCP debug ports sockets may be implementedindependent of data sockets, including at different points in the OCPsystem from where a Data port may be implemented.

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

Figure5 ” Single-core Debug Solution with Wiring through OCP-Debug Sockets

Figure 5 above shows asimple system where debug IP blocks are implemented and integrated intoa modular OCP system interconnect structure that is created fromlibrary IP blocks around a bus fabric (as described in the SPIRIT XMLconceptual framework). Debug signals go through the system bus fabricand is contacted through an OCP debug port.

In general, while debug socket functions are passive and notintrusive to system operations or performance, some debug relatedoperations (cross triggering, etc.) may have interaction with otherparts of the system operation

Debug InterfaceDefinitions. The programming of registers that contain eitherconfiguration or status information in the debug IP blocks may beJTAG-mapped or Memory-mapped. Either one or both modes of control andaccess are acceptable, based on specific system requirements as shownin Figure 6, below.

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

Figure6. A multi-core debug socket implementation

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

A JTAG-only debug interface addresses many non-real time debugoperations, interfacing to debug components on different cores and toset up and synchronize an OCP system into a debug mode. Even in thecase of “memory mapped” debug blocks the processor control can operateover this JTAG port.

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

Higher performance debug architectures may include independent resetand independent clock signals for the debug system synchronized to thedebugger interface. An independent clock allows more flexible supportof asynchronous or clock gated systems.

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

Core (Master)Debug Socket Interfaces. OCP debug programming models shouldallow user defined debug configurations based on the debug scenario andallow bi-directional debugger accesses to be consistently controlledvia these debug interface signals.

Signals defined in the OCP-IP debug environment include debuggerinitiated debug mode request (rd/wr) and core acknowledge signals tothe 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 situationsand forcing completion of locked actions (Force, abort, suspend) for acore in debug status OCP peripherals interfaces would also need to be”debug aware”, to recognize and synchronize with processor cores orother bus masters that enter debug mode.

Peripheral(Slave) Debug Socket interfaces . A peripheral debug interfaceshould insure that, for Debugger OCP transactions, any debuggerinitiated debug mode operation reads peripheral informationtransparently, while preserving the system state.

Depending on debug scenarios and the relationship between the localhardware process and the software process, peripherals should monitorthe debug state and may need to take several actions to synchronizewith the debug processor and allow Processing of OCP transactionsinitiated by debugger to be handled differently than those initiated bythe application software:

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

2. Stop peripheral or otherlocal hardware process when a processor enters the debug state. Thiscan get complicated, since the peripheral may be potentially shared oraccessed by several OCP masters in the architecture.

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

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

– FREE , which allows keepingthe local hardware process free running or make it sensitive to thedebugger input.
– SOFT, which allows waitingfor a clean boundary before stopping the local hardware process whenextra latency is acceptable.

CrossTriggering Socket Interfaces. Cross triggering and theirassociated system level control are important for debug of complex SoC.Cross triggering allows global and distributed event recognition andmulti-core triggering to identify and isolate events occurringthroughout the system.

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

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

Figure7. Cross-triggering in the OCP-bus

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

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

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

OCPSynchronized Run Control. Synchronized Run Control supportsclock synchronized program execution of two cores that would runasynchronously in normal case. That makes it possible to time align theinstruction streams to study interdependency.

OCP TrafficMonitoring and Trace Interfaces. Traffic monitoring and trace isoften a critical debug feature to able to analyze on chip behavior.System monitoring and trace can be done at signals on the data socketor in the bus fabric itself.

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

1) Continuous (or at leastlong duration) system monitoring
2) Filtering based on OCPoperations (ex. Initiator, thread, address range, DMA logical channel)
3) Trace capture of both OCPtransactions and non-OCP qualifying events
4) Transaction filtering andalignment of requests and responses
5) Elastic trace bandwidth atOCP System traffic peaks
6) Support for SWinstrumentation interleaving with the trace flow
7) Support interleaving severaltrace flows from different trace points or channels
8) Support Multi-threaded dataobservation including system trace datareads from the JTAG or from application SW Since trace is dataintensive, high performance interfaces may be required.

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

`Extended (Optional) DebugInterfaces
Additional extended debug signals are needed to support applicationspecific or optional functionality for a targeted on-chip system. Theseinclude debug of systems with Power Islands or Secure subsystems (whichmay be implemented in a variety of ways in different designs). As withother debug signals , communication is anticipated to handled viaon-chip debug blocks controlled and configured via JTAG ormemory-mapped register communications

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

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

A key advantage that the OCP socket architecture provides is astandardized and robust set of interfaces that reduce the risk to IPvenders and users in developing interoperable IP and the systemdeveloper in applying that IP into systems.The addition of DebugInterface Sockets addresses this emerging issue of enabling complexon-chip debug and how the integrated approaches can be applied tocurrent and future SoC designs.

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

Neal Stollon is PrincipalEngineer at HDL Dynamics, an IPcompany developing on-chip debug solutions. He has previously workedfor Texas Instruments, Alcatel, LSI Logic, and MIPS Technologies. Heholds a Ph.D in EE from Southern Methodist University and is aProfessional Engineer based in Texas.

Bob Uvacek is OCP-IP DWGChair and Pixelworks seniordirector, and has design experience and interests in VoIP DSP and chipmaking, 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 designerwith the Texas Instruments WirelessBusiness Unit, focused on SOC debug architectures on the OMAPplatforms.

Leave a Reply

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