4.1.2. CTI handshaking, synchronization, and clocks

This section describes handshaking, synchronization, and clocks in the following sections:

Interfaces handshake protocol

The CTI does not interpret the signals on the Channel Interface (CI) or Trigger Interface (TI). If handshaking is enabled it is assumed the events are edge-triggered. As a result, closely occurring events can be unreliably recognized. An event is transmitted as a level. If you require edge detection or single pulse output you must implement the necessary shaping logic in the external wrapper.

To avoid any incompatibility, the following protocol has been defined:

  • Only logic 1 is interpreted as an event.

  • If the handshake is enabled, an output must stay active until an acknowledgement by hardware or optionally acknowledged by software for the TI is received, even if the acknowledge signal driver is deactivated.

If the handshaking is enabled, the CTI can only handle one-shot events. If events are close to one another, or multi-shot, and mapped to the same channel they are possibly merged into one event on an output trigger. For debug events such as breakpoint, trace start, and trace stop this does not cause a problem because input events mapped to the same triggers are required to do the same thing.

Events arising from different interfaces but mapped to the same channel might also be merged. This is acceptable because the mapping logic would have been programmed to enable this. Events can be merged because blocks handshake between asynchronous clock domains or channels events are mapped onto the same output trigger.

If the events sent on the CTI emanate from the same clock domain then you can bypass the handshaking and synchronizing logic. The output does not receive an acknowledgement. In such cases you can use the CTI to transmit multiple shot events. The output has to remain active for at least one clock cycle to ensure it is captured at the destination interface.


Systems where events broadcast into the CTI can emanate from asynchronous clock domains must observe the following rules:

  1. Register input events. Any signal that is an input to the CTI must be glitch-free to avoid any false event. The built-in synchronizers must be enabled unless external synchronization has been performed.

  2. Synchronize output events. The outputs of the CTI must be synchronized to the local clock domain before being used by the subsystem, if such synchronization is not already present in the subsystem.

Register input events

The concern here is that a glitch on an output of the subsystem is propagated in the CTI and can be interpreted as an event. Also, the synthesis tools do not provide the necessary mechanism to constrain signals so that they are glitch free.

For example, in an ARM9E processor design, DBGACK is the output of a combinatorial circuit, that is, a three-input OR gate. There is no way to ensure that a change of state on the inputs does not result in a glitch on the DBGACK signal that can be fetched by an asynchronous circuit.

A single register can be used in this case provided the signal is in the same clock domain as the CTI. Alternatively, you can enable the synchronization logic in the CTI for that specific trigger input adding an extra clock cycle to the latency.

Synchronize output events

Figure 4.2 shows that a standard two-register synchronization is used.

Figure 4.2. Standard synchronization


It is important that you consult the design rules on the target process and the standard cell libraries to check if there are any restrictions or recommendations in relation to synchronizers. For example, the library rules might require the use of specially designed synchronization registers, or require that registers forming a synchronization chain must be placed in close proximity to each other.


The latency corresponds to the number of cycles necessary from the time one signal enters the ECT system until it is propagated to another core. The path in the CTI and CTM is combinatorial, so that the latency is only because of the handshaking circuits. This means that, in the worst case, the latency is the sum of:

  • one clock cycle of the CTI sending the event to the matrix, or removal of the glitch

  • the combinatorial delay caused by the propagation of an CTITRIGIN event to an CTITRIGOUT output

  • two clock cycles of the CTI receiving the event from the matrix, or synchronization to the clock of the receiving device.

In certain cases, it might be possible to reduce this latency:

  • If the signal sent by the core is the output of a flip-flop, you do not have to register the signal because it is glitch-free.

  • If the core being interfaced to already features synchronization logic internally, for example, the processor has been specified to receive an asynchronous signal.

  • If all the subsystems are synchronous, the TI bypass signals, TISBYPASSACK and TISBYPASSIN, can be activated. However, this path must respect the layout and synthesis timing constraints.

  • If the CTM and CTI clocks are synchronous, the CI bypass signals, CISBYPASSACK and CISBYPASSIN can be activated.

Clock domains

In most systems the CTICLK is connected to the same clock as its local processor and the CTMCLK is connected to the fastest processor clock in the system so reducing the trigger latency and the requirement for clock enable ports.

If a CTI is going to be disabled while the processor enters a clock stopped mode, ARM recommends the following:

  • The CTI turns off the event-to-channel mapping, so that unwanted events are not generated to the CTM.

  • The channel-to-event mapping circuit is turned off or disabled for a few clock cycles after the clock is on.

  • This version of the CTI must not be connected to clocks that might be removed, that is stopped. This version of the CTI must not be placed within a power domain that can be turned off. In these scenarios it is recommended that CTICLK is the same as CTMCLK.

When a processor clock is stopped, for example, waiting for an interrupt, the corresponding CTI can receive an event from the CTM. When the CTI clock is the same as the subsystem clock and the handshaking is not bypassed, the CTM keeps the signal active until an acknowledgement is received, which only occurs when the clock is started again. In this case, out-of-date events can happen on the core. This does not inhibit the channel being used by other processors.

However, if the CTI clock differs from the local processor clock, for example, it is gated differently, it is possible for the CTI to raise an event to the core using CTITRIGOUT, while the processor clock is off. If raising an event to the core must be avoided, the processor must disable its CTI before stopping the clock.

Linking CTIs and CTMs

Where the clock used on a CTI and a connected CTM, or CTM to CTM, or CTI to CTI, is asynchronous, then both the handshaking logic and synchronization registers must be left enabled, that is, CIHSBYPASS and CISBYPASS must be tied LOW.

If both devices have synchronous clocks then synchronization can be bypassed, CISBYPASS tied HIGH, to reduce latency.

If both clocks are the same, that is, CTMCLK = CTICLK, and the channel is required to send multi-shot events, the handshaking can be bypassed by tying CIHSBYPASS HIGH.

Copyright © 2004-2009 ARM. All rights reserved.ARM DDI 0314H