Cross-trigger interface programmers’ model

PART D: ARMV8 EXTERNAL DEBUG

12 EMBEDDED CROSS-TRIGGER

12.3 Cross-trigger interface programmers’ model

Each cross-trigger interface (CTI) block has up to 32 input triggers (from the processor) and 32 output triggers (to the processor), both numbered from 0 to 31. The cross-trigger matrix (CTM) passes events between CTI blocks over channels. The CTM can have up to 32 channels.

A v8-A processor must include a cross-trigger interface, and must implement at least the input and output triggers defined in this architecture. The number of channels in the cross-trigger matrix is IMPLEMENTATION DEFINED, and discoverable via CTIDEVID, but must be at least 3.

The CTM must connect to at least all processors in the same Inner Shareable domain as this processor. ARM strongly recommends that the CTM connects to all processors implementing a CTI interface in the system.

This includes v7-A and other processors which can be connected using a CoreSight CTI module.

Note: In a uniprocessor system the CTM is OPTIONAL. The CTM may be used to connect to other CTI modules for non-processors, such as triggers for system visibility components. ARM recommends the CTM is implemented.

Any CTI connected to a processor that is not v8-A must implement at least the Debug Request, Restart and Cross-halt trigger events.

For more information on the CTI, see [CTI]. v8-A specializes the generic CTI by defining roles for each of the implemented input and output triggers.

12.3.1 Description and allocation of CTI triggers

Table 57 and Table 58 list the trigger events defined by the architecture and their trigger numbers.

Numbers Source Destination Event description

0 CTI Processor Debug Request trigger event on page 182 1 CTI Processor Restart Request trigger event on page 183 2 CTI IRQ controller Generic CTI Interrupt trigger eventon page 184

3 - - Reserved

4, 5, 6, 7 CTI Trace extension OPTIONAL Generic Trace External Input trigger events on page 184 Table 57: Allocation of CTI output trigger events

Note: Output triggers from the CTI are inputs to other blocks.

Numbers Source Destination Event description

0 Processor CTI Cross-halt trigger event on page 183

1 Processor CTI Performance Monitors Overflow trigger event on page 183

2, 3 - - Reserved

4, 5, 6, 7 Trace extension CTI OPTIONAL Generic Trace External Output trigger events on page 184 Table 58: Allocation of CTI input trigger events

Note: Input triggers to the CTI are outputs from other blocks.

This is the minimum set of trigger events defined by the architecture, however:

 The Generic trace external input and output trigger events are only required if the OPTIONAL Trace extension is implemented. If the OPTIONAL Trace extension is not implemented, these trigger events are reserved.

 Support for the Generic CTI Interrupt trigger event is IMPLEMENTATION DEFINED, as details of interrupt handling in the system (including any interrupt controller), are IMPLEMENTATION DEFINED. Details such as how the CTI interrupt is connected to an interrupt controller and its allocated interrupt number lie outside the scope of the architecture. ARM strongly recommends that implementations provide a means to generate interrupts based on external debug events.

 The other trigger events are required.

A v8-A implementation can extend the CTI with additional triggers starting from number 8.

Debug Request trigger event

This is an output trigger event from the CTI, an input trigger event to the processor, asserted by the CTI to force the processor into Debug state. The trigger event is asserted until acknowledged by the debugger writing 1 to CTIINTACK[0].

If the processor is already in Debug state, the processor ignores the trigger event, but the CTI continues to assert it until it is removed by the debugger.

See also:

 Exiting Debug state on page 159

 Multicycle Restart Request trigger event on page 305

 [PIL].

Cross-halt trigger event

This is an input trigger event to the CTI, an output trigger event from the processor, asserted by a processor when it is entering Debug state.

Notes:

— Once the processor has entered Debug state, the trigger is deasserted.

— To reduce the latency of halting, an implementation is recommended to issue the Cross-halt trigger event early in the committed process of entering Debug state; that is, there is no requirement to wait until all aspects of Debug state entry have completed before issuing the trigger event, but speculative emission of Cross-halt trigger events is not allowed. The Cross-halt trigger event must not be issued so early that a subsequent Debug Request trigger event into the processor that might have derived from the Cross-halt trigger event, will be recorded in the EDSCR.STATUS field.

Performance Monitors Overflow trigger event

This is an input trigger event to the CTI, an output trigger event from the processor, asserted each time the processor asserts a new Performance Monitors counter overflow interrupt request. See Pseudocode details of Performance Monitors on page 116.

If the CTI supports multicycle trigger events then the trigger event remains asserted until the overflow is cleared by a write to PMOVSCLR_EL0. Otherwise, the trigger event will not be asserted again until the overflow is cleared by a write to PMOVSCLR_EL0.

Otherwise, the trigger event is asserted when the value of the PMU Overflow Status Register changes from zero to a non-zero value.

Notes:

— This does not replace the recommended connection of Performance Monitors Overflow trigger event to an interrupt controller. Software should be able to program an interrupt on Performance Monitors overflow without programming the CTI.

— Events can be counted when ExternalNoninvasiveDebugEnabled() == FALSE, and in Secure state when ExternalSecureNoninvasiveDebugEnabled() == FALSE. Software should be aware that overflow trigger events are nevertheless visible to the CTI.

— If software clears the PMU Overflow Status Register by writing to PMOVSCLR_EL0 at the same time as an PMU counter overflows, this is a race condition. It is UNPREDICTABLE whether a trigger event is generated for the new overflow condition, unless the PMU Overflow Status Register was previously zero and is non-zero following both events.

Generic Trace External Input trigger events

These are ouput trigger events from the CTI, input trigger events to the OPTIONAL Trace extension, used in conjunction with the Generic Trace External Output trigger events to pass trigger events between the processor and OPTIONAL Trace extension, between Trace extensions using the CTM, or between Trace extensions and any other component attached to the CTM. There are four Generic Trace External Input trigger events.

The trigger events are self-acknowledging, meaning no further action is required by the debugger to remove the events.

Generic Trace External Output trigger events

These are input trigger events to the CTI, output trigger events from the OPTIONAL Trace extension, used in conjunction with the Generic Trace External Input trigger events to pass trigger events between the processor and OPTIONAL Trace extension, between Trace extensions using the CTM, or between Trace extensions and any other component attached to the CTM. There are four Generic Trace External Output trigger events.

Generic CTI Interrupt trigger event

This is an output trigger event from the CTI, an input to an IMPLEMENTATION DEFINED interrupt controller, and can be used to transfer trigger events from the processor, Trace extension, or any other component attached to the CTI and CTM, to software as an interrupt. Should be connected to the interrupt controller as at least a private peripheral interrupt for the originating processor.

Notes:

— ARM recommends this is private peripheral interrupt, but implementations might instead make this trigger event available as a shared peripheral interrupt.

— [GICv3] reserves a private peripheral interrupt number for this interrupt.

It is IMPLEMENTATION DEFINED whether this trigger event is:

 self-acknowledging, meaning no further action is required from the debugger, meaning the interrupt controller must treat it as a pulse or edge-sensitive interrupt.

 acknowledged by the debugger writing 1 to CTIINTACK[2], meaning the interrupt controller must treat it as level-sensitive interrupt.

ARM recommends this is a self-acknowledging trigger event.

Note: In v7-A systems it is common for the CTI interrupt to be a level-sensitive interrupt, meaning an interrupt handler must clear the interrupt at source using CTIINTACK. This is a change for v8-A.

12.3.2 CTI registers programmers’ model

The CTI registers programmers’ model is described Cross-trigger interface registers on page 224.

See also Memory-mapped accesses to the external debug interface on page 193.

12.3.3 CTI reset

The CTI is reset by External Debug reset. See Cross-trigger interface register resets on page 226 for details of CTI register resets. All CTI output triggers and output channels are deasserted on External Debug reset.

12.3.4 CTI authentication

The CTI ignores the state of the IMPLEMENTATION DEFINED authentication interface. This means that:

 CTITRIGINSTATUS and CTICHINSTATUS show the status of the input triggers and input channels respectively, regardless of the value of ExternalNoninvasiveDebugEnabled().

Note: The processor will not generate the Cross-halt trigger event and the Trace extension will not generate Generic Trace External Output trigger events when

ExternalNoninvasiveDebugEnabled() == FALSE. However, the processor can generate Performance Monitors Overflow trigger events.

 The CTI can generate external triggers regardless of the value of ExternalInvasiveDebugEnabled().

Note: The processor will ignore Debug request and Restart Request trigger events when ExternalInvasiveDebugEnabled() == FALSE. The Trace extension will ignore Generic

Trace External Input trigger events when ExternalNoninvasiveDebugEnabled() == FALSE.

The behavior of Generic CTI interrupt requests is part of the IMPLEMENTATION DEFINED handling of these interrupts, but it is permissible that an interrupt controller will receive these requests even when ExternalInvasiveDebugEnabled() == FALSE.

In document ARMv8 Debug Architecture PRD03 PRDC 010486 59 0 (Page 181-185)