Browse Prior Art Database

Multi-Group Software Cross-Triggering Breakpoints for External Mode Debuggers

IP.com Disclosure Number: IPCOM000207787D
Publication Date: 2011-Jun-10
Document File: 5 page(s) / 69K

Publishing Venue

The IP.com Prior Art Database

Abstract

There is a plurality of multicore processors that do not provide a hardware implementation for multi-group cross-triggering breakpoints. Despite the lack of hardware support, there are requests for external mode debuggers (using test access port or other external debug port) to handle multi-group cross-triggering for breakpoints. This publication provides a software mechanism for implementing cross-triggering breakpoints with a skid level close to a hardware implementation. This solution addresses external mode debuggers for homogenous or heterogeneous multicore processors that do not provide a flexible hardware implementation for multi-group cross-triggering breakpoints.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Multi-Group Software Cross-Triggering Breakpoints for External Mode Debuggers

Abstract

There is a plurality of multicore processors that do not provide a hardware implementation for multi-group cross-triggering breakpoints. Despite the lack of hardware support, there are requests for external mode debuggers (using test access port or other external debug port) to handle multi-group cross-triggering for breakpoints.

This publication provides a software mechanism for implementing cross-triggering breakpoints with a skid level close to a hardware implementation. This solution addresses external mode debuggers for homogenous or heterogeneous multicore processors that do not provide a flexible hardware implementation for multi-group cross-triggering breakpoints.

Definitions:

·         Cross-triggering (CT):

Cross-triggering occurs when one processor in a group stops because of an internal or an external event, and this causes other processors from group to stop.  For example, if CPU1 triggers a breakpoint that causes it to stop, CPU0 and CPU2 also stop as a result.

·         Multi-group cross-triggering:

Multi-group cross-triggering represents the capability to define multiple groups for cross-triggering. For example one group may contain CPU0 and CPU 1 while another group may contain CPU 4 and CPU 5. There are processors that implements only one-group cross-triggering HW mechanism.

·         Loose Cross-triggering:

In both hardware and software environments, debuggers can cross-trigger the processors loosely. This is characterized by a large skid, of as much as several seconds (many million instructions), because of the way the debugger is connected to the processors. A large skid might also arise because there is no hardware cross-triggering mechanism.

·         Tight Cross-triggering:

In a hardware environment, debuggers use a closely synchronized system where this is supported by the underlying processor or emulator. This has a very short skid, usually a few microseconds or less and only a few instructions.

A detailed presentation

The proposed software cross-triggering mechanism is embedded into a library which is linked with the debugged application and configured by the external host debugger.

The library provides the following key elements:

·         a cross-triggering trap handler

·         an inter-core interrupt handler

·         a shared memory area between processor cores containing the following data structures:

Ø  a cross-triggering groups’ matrix

Ø  a cross-triggering signaling flags vector

The cross-triggering groups’ matrix contains the cross-triggering groups’ information which is initialized by the host debugger. The groups’ matrix can be dynamically modified at runtime.

The cross-triggering signaling flags are used to determine if a core was interrupted due to a cross-triggering event or due to any other applic...