OCP SoC instrumentation solutions involve more than just trace - Embedded.com

OCP SoC instrumentation solutions involve more than just trace

Rapid analysis at the systems level helps get your applications to market quickly.

On-chip analysis can effectively improve our understanding of complex embedded systems, such as Open Core Protocol (OCP)-based architectures. OCP is a standards-based embedded-bus interface and multicore IP integration protocol defined by the OCP-IP industry consortium. For OCP level systems integration, real-time performance analysis is often a priority for getting products to market quickly, and embedded instrumentation analysis that can be used with emulators, prototypes, and production silicon can provide systems information and control that go beyond simulation based analysis

System On-Chip Instrumentation (System OCI) is an intellectual- property (IP) subsystem that gives designers the ability to control, trace, and debug embedded signals in a way that provides visibility into system interfaces and operations. System OCI typically works with processor-specific run-control and trace interfaces and other IP debugging systems to provide a comprehensive view of the on-chip operations. The on-chip systems analysis also enables systems designers to optimize the performance of multicycle operations for an OCP interface and the global subsystem of shared interfaces and peripherals.

In complex system architectures, designers always face tradeoffs that effect architecture initialization, stalling and deadlocking, transmission efficiency, latency, saturation, resource conflicts, and other bus operations, all of which can have a direct impact on the performance and overall system operation. Analysis at this level requires visibility and control of key signals, both to configure the OCP parameters and to determine if the result is meeting the system requirements. For embedded OCP interfaces, the instrumentation must allow adequate bus-signal visibility, without halting or impacting system operations and allow modification of parameters directly and simply.

As shown in Figure 1, some of the on-chip debug control options available using System OCI include direct control of OCP signals and system configurations through two methods: cross-triggering interfaces and externally controlled registers. Both methods have advantages and limitations in providing debug control of an OCP system.

View the full-size image

Embedded cross triggering
Event monitoring and triggering IP can monitor signals from diverse points in the architecture. Cross-trigger interfaces can be implemented between multiple processors, buses, and other on-chip components and interfaces to provide at-speed and low-latency trigger monitoring and control. Sophisticated on-chip trigger systems can include a range of combinatorial, sequential, and timing-based triggering conditions and actions. Cross-trigger configurations can be created using relatively moderate amounts of on-chip logic, with JTAG configuration of registers allowing on-chip setup of different trigger conditions.

Examples of control operations include the ability to synchronize the configuration and dynamically change system registers; set hardware interrupts and other system conditions; force processors into special modes; drive control inputs to IP blocks; set processor mode signals; control system halts or stalls; and control or synchronize off-chip systems or instruments. Cross trigger can also include triggering from control actions to off-chip system components, including other types of instrumentation. Because the trigger system can operate in real time, the cross triggering can be set up to capture and respond to real-time events in the SoC.

Externally controlled debug register
Writing to debug-related registers provides a way to directly inject and later monitor information on the chip. The register can be manually loaded or read from a JTAG interface under program or tool control. Because the values are coming from a host interface, writing to the register in real time is limited in many situations, and the primary use is in setting or changing initial system conditions. The interface of choice is JTAG, as it's part of most systems and provides a directly controllable and otherwise transparent interface that doesn't require writing processor code or making system calls that change the system operation and execution. In many cases, the ability to manually change the setup of embedded signals, either for mode and configuration control, or to simply to put a signal into a known state can significantly improve the ease of debug and rapid verification of hardware and applications.

All three elements of the OCP's on-chip analysis interfaces–register control, cross-triggering, and trace–can be used interoperably to increase their flexibility:

• Both trace and register values can be used as cross trigger logic inputs.

• Trigger outputs can be dynamically captured for analysis, either in the debug register or in trace.

• Trigger actions can drive the register operations as well as trace enables.

An example of using the integration of on-chip triggering and loadable registers to create a powerful analysis tool is in implementing a JTAG-programmable OCP bus transactor. Such a tool provides a useful and simple way to configure cores, load or read information in peripherals, or gather information to analyze timing-based OCP conditions (such as latency, throughput, saturation, and deadlocks) without involving the processor or other on-chip system resources. The transactor enables the coordinated set of JTAG-controlled registers and triggering resources to implement a simple OCP master to control and debug bus-traffic operations.

Basic OCP bus transactions follow a relatively simple bus protocol that can be modeled as a state machine. Initial conditions and enables of the bus-transaction commands are set up using externally controlled registers. Real-time control of the OCP transaction state machine can be performed at the OCP socket level, using a sequential trigger logic block to monitor triggering bus condition inputs and trigger action outputs, which implement a state machine that's compliant with the OCP transaction protocols. Using the configurable trigger logic provides a relatively small and totally programmable bus transactor, which, coupled with a user-programmable triggering system, can be dynamically modified for different applications.

For initial OCP bus-master transactor implementation, eight OCP signal fields are typically required (four inputs and four outputs):

• Bus-master outputs : MCmd , MAddr , MData , MDatavalid

• Bus-master inputs : SCmdAccept , SResp , Sdata , SDataAccept

A basic implementation of a bus transactor would support only simple read and posted write data operations and may require stalling between operations to ensure synchronization of signaling operations (in other words, MData must occur concurrent with MDatavalid , and SDataAccept occurs concurrent with Sdata ). More advanced OCP operations, such as bursting, may require additional (dedicated) logic, to support full speed bursting. Figure 2 shows signal timing.

View the full-size image

A transactor bus-master operation can be initiated either from an external register load or from trigger output signals acting on specific bus-monitoring operations. Address and data for individual bus transactions can also be written from the externally controlled registers, although this may be a slower manual process or require multiple cycles. Alternatively, writing of regular (in other words, incrementing or other simple pattern) address and data can be controlled by counters or by logic that's enabled by trigger signals. Data and other OCP signals or performance data may also be traced (sequentially or periodically), with the bus-master operations optionally stalled during JTAG data download phase, to avoid a loss of continuity.

Neal Stollon is a principal engineer HDL Dynamics, a consulting company addressing on-chip instrumentation solutions. He has over 20 years digital design and processor development experience. Dr. Stollon has a Ph.D in EE from Southern Methodist University. He can be reached at .

Leave a Reply

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