Using the ELA-500 with Arm DS

A tutorial showing how to use the CoreSight ELA-500 with Arm Development Studio (Arm DS) to debug a real-world deadlock scenario

Introduction Before you begin Importing the ELA-500 DTSL use case scripts Configuring the ELA-500 use case scripts Running the ELA use case scripts Capturing the ELA trace data Analyzing the ELA trace capture


The Arm CoreSight ELA-500 Embedded Logic Analyzer (ELA-500) provides low-level signal visibility into Arm IP and third-party IP. When used with a processor, the ELA-500 provides visibility of:

  • Load
  • Stores
  • Speculative fetches
  • Cache activity
  • Transaction life cycle.

None of previous items are available through instruction tracing.

CoreSight ELA-500 enables fast hardware assisted debug of hard-to-trace issues, including data corruption and dead or live locks. The ELA-500 also accelerates debug cycles during complex IP bring-up and assists with post deployment debug.

CoreSight ELA-500 offers on-chip visibility of both Arm and proprietary IP blocks. Program trigger conditions over standard debug interfaces either by an on-chip processor or an external debugger.

The problem with traditional debug methods

Processors can stop functioning because they are locked-up, also known as deadlocked. One common deadlock scenario happens when a processor initiates memory transactions to a location in the system that cannot response or handle the request. A deadlock might happen if there is no bus Completer or the bus Completer has limitations like it does not support Burst transactions.

In a perfect world, systems are designed so the entire physical memory map is fully populated. A fully populated memory map means that all memory transactions, to all addresses, correctly respond with either a valid transaction result or a bus fault. However, for certain designs, this memory model is not implemented.

Places in the memory map that are not populated can be referred to as “holes”. Aggressive speculation and prefetching performed by Arm processors means memory map “holes” are more likely to be exposed during execution. This exposure can happen even if the software does not explicitly reference the memory “holes”.

Software can prevent memory “hole”-related issues by correctly configuring the MMU translation tables to accurately describe the physical memory map. Software can configure any memory map “holes” as being invalid. Configuring the MMU this way prevents the processor from making any physical bus transactions to a “hole”, which prevents a deadlock scenario.

Debugging memory “hole”-related deadlock scenarios cause an issue when debugging using traditional methods, like external debug, and instruction and data trace. If an incomplete memory transaction occurs, a processor might not enter halt mode debug. If the core does not enter halt mode debug, the external debugger is unable to break the processor and inspect its internal state. In this situation, trace capture might still be available. However, trace does not provide a record of the Speculative or prefetched transactions that could be responsible for the deadlock.

When deadlock scenarios occur, to trace the external bus transactions made by the processor, use the CoreSight ELA-500. Depending on the board implementation, the ELA-500 allows you to trace both explicit and Speculative transactions. This tutorial shows how to work with the use case scripting capabilities of Arm Development Studio (Arm DS). In particular, demonstrating the example CoreSight ELA-500 use case scripts shipped with Arm DS.

About the CoreSight ELA-500

The ELA-500 implements up to 12 Signal Groups, each containing 64-bit, 128-bit, or 256-bit signals. The connections between the signals in the Signal Groups depend on the system and the IP that it is connected to. The specific signal interfaces are documented in the relevant IP documentation. These documents might only be available to Arm IP licensees. Arm IP connected to an ELA is supplied with a JSON file. The JSON file documents and annotates the signal group connections for that particular IP, in a machine-readable format. Arm DS interprets the JSON file to allow seamless debugging of a piece of IP using Arm DS and the ELA-500.

Signals typically consist of debug signals like status or output, and qualifiers like triggers. Qualifier signals might be required to determine that the debug signal is valid. Debug signals are valid when the qualifier signal is asserted.

The example board

This tutorial uses a board with a Cortex-A72 and an ELA-500 to explore a lock-up scenario. This Cortex-A72 and ELA-500 system utilizes the LAK-500A. The LAK-500A is an Integration Kit for the ELA-500 and the Cortex-A72. The Integration Kit is an add-on to the ELA-500. The LAK-500A exposes some pre-defined debug observation ports to the Cortex-A72 ELA Signal Groups, and provides the corresponding JSON signal-mapping file.

As part of the LAK-500A, a Cortex-A72 debug observation port exposes the physical read address signal bus ARADDR and an address valid signal, ARVALID.

Note: For this tutorial, these signal names are obfuscated.

These signals are required to determine the read addresses issued by the core, before the lock-up scenario. In this tutorial, while a memory copy routine is executed, we monitor these signals with the ELA-500 so we can do a post analysis of the core read transactions. Analyzing the read transactions helps us identify which transaction might have caused the core lock-up.