ARM Technical Support Knowledge Articles

Why is trace bandwidth so limited on PB-A8?

Applies to: PB-A8


The test chip used on the PB-A8 development system has an ETM (Embedded Trace Macrocell). It does not contain the remainder of the CoreSight system components required for JTAG debug or real time Trace, namely the DAP (Debug Access Port), the TPIU (Trace Port Interface Unit), Funnel and CTI (Cross-Trigger Interface). Due to project timeline constraints, the decision was made to produce the test chip without these elements included.

JTAG debug and Trace are still possible on this system because the CoreSight components are incorporated into the "Debug FPGA" on the PB-A8 motherboard. The following FAQ describes how to get trace working on the PB-A8 system: How do I configure RVD_4.0/RVI_3.3 to capture ETM Trace using RVT on the PB-A8?.

ARM's RealView Trace TPA (Trace Port Analyzer) unit can accept a trace clock of ~125MHz for first generation units or ~200MHz for the second generation, but on the PB-A8 system, the trace clock is limited to 25MHz due to the FPGA implementation of the trace interface. The reference clock for the Trace sub-system runs at 50MHz, which means that the TRACECLK output is fixed at half of that: 25MHz.

The default clock speed for the Cortex-A8 CPU in the test chip is 750Mhz. With such a disparity between the CPU clock and Trace clocks, it is highly likely that any kind of high bandwidth tracing will result in lost trace data.


It is not possible to increase the speed of the Trace clock, but it is possible to reduce the quantity of trace data produced. There are several ways of doing this.

1) Use the widest possible trace port. There are two Trace Mictor sockets on the PB-A8 motherboard. On its own, J54 can provide up to 16-bit trace. Using both J54 and J55 together will expand the trace port to 32-bits. The downside to this method is that compatible TPA hardware must be used. For the ARM RealView Trace TPA, it is necessary to use the "32-bit Dual-Mictor trace probe" ( PCB part number HPI-0177A) to capture 32-bit trace from both Mictors simultaneously. This double-width trace probe only works with RVT v2 hardware.

2) Use Trace triggering to capture trace only during certain parts of program execution. The downside to this is that it just may not be possible to capture all the required data to facilitate easy code debug.

3) Use trace filtering to further reduce trace output. Trace can be limited to instruction tracing only, data only and whether addresses are also output from the trace port. The downside to this is again that it may not be possible to capture the desired quantity of trace data.

A detailed explanation of steps 2 and 3 are beyond the scope of this FAQ but instructions are given in the RVD Trace User Guide.

4) Reduce the speed of the CPU clock so that the trace data is emitted at a reduced rate. It is possible to reduce the CPU clock but keep the test chip bus clocks relatively unchanged, which will help keep up the relative performance of the software being tested. Please refer to the following FAQ for instructions on changing the CPU clock settings: How do I change the test chip reference clock and PLL settings on PB-A8?

Rate this article

Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential