In this section of the guide, we provide some trace infrastructure examples. These examples illustrate:
- The general flow of trace data from trace source to trace sink
- The interaction of non-trace components with the trace infrastructure
- That trace infrastructures can have varying levels of complexity
Refer to your target designer and target documentation to learn how your target implements its trace infrastructure.
Note: The trace infrastructure examples use ETMs as the processor instruction and data trace source. This is because most Arm-based systems use ETMs. Other core trace sources, for example PTMs, could be used in the same way.
ETM trace infrastructure examples
The following diagrams show two similar trace infrastructure examples that are centered around ETM trace generation:
In both examples, an ETM is used like a trace source to generate trace data for an Arm core. The ETMs generate instruction trace, and potentially data trace, for the cores that they are connected to. The ETM-generated trace data is passed to a trace sink over the ATB. Example 1 uses an ETB for a trace sink, and Example 2 uses a TPIU.
In systems where the trace sink is an ETB or an ETR, the trace data is stored on-chip for later retrieval by a debugger. If the trace sink is a TPIU, a debug probe is required to capture the trace data that is output by the TPIU.
Multiple core trace infrastructure example
The following diagram shows a trace infrastructure example in which more than one core is traced:
This example shows a mix of different types of cores: two Cortex-A class cores and one Cortex-M class core. This type of configuration is referred to as a heterogeneous system. The Cortex-A class cores each have an ETM as their trace source to generate core trace data. The ETMs generate instruction trace, and potentially data trace, for the cores that they are connected to. The Cortex-M class core is connected to an ITM to collect instrumentation trace from that core. There is also an STM to collect system trace for the target.
All the trace sources pass trace data over the ATB to a trace funnel. This means that all the ATBs can be combined before they are passed to the trace sinks. There are three trace sinks in the system: ETF, ETR, and TPIU.
The ETF can be configured either as a circular buffer, to capture trace data, or as a FIFO, to smooth out trace data fluctuations.
From the ETF, the replicator duplicates the ATB before it reaches the ETR and the TPIU. The ETR routes the combined ATB to system memory through AXI, the system interconnect. The trace data that is stored in the system memory can later be retrieved by a debugger for analysis. In the case of self-hosted debug, the trace data in the system memory could be consumed by another core on the target. The TPIU operates in the same way as in the ETM trace infrastructure example.
CTI trace infrastructure example
The following diagram shows a trace infrastructure example with CTI connections:
This example shows four Cortex-A class cores and one Cortex-M class core.
All the Cortex-A cores have their own ETM to generate core trace data. Unlike the multiple core trace infrastructure example, the Cortex-M core has both an ETM and an ITM. This means that core and instrumentation trace data are generated.
The configuration also includes an STM to collect system trace data for the target.
The output from the ETMs, ITM, and STM are routed to a trace funnel to combine into one ATB. The single ATB from the funnel is routed to an ETF. The ETF in this example operates like the ETF in the multiple core trace infrastructure example.
From the ETF, the ATB is routed to a replicator. This example includes an ETS that allows the trace data to be passed off-chip using an HSSTP. An HSSTP is useful if the target is running at high frequencies, or if the target has many trace sources that must be captured concurrently.
CTIs are connected to the ETF, ETR, and ETS. If the CTIs are programmed appropriately, they allow the ETF, ETR, and ETS to pass halt requests to the core CTIs. For example, the ETR can send a halt request through the associated CTIs to the cores when the circular memory buffer is full. The halt request halts the cores, which allows the debugger to collect the trace data before the ETR wraps. This means that no core trace data is lost.