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

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

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

CoreSight ELA-600 enables swift hardware-assisted debug of otherwise hard-to-trace issues, including data corruption and dead or live locks. It also accelerates debug cycles during complex IP bring up and provides extra assistance for post deployment debug.

CoreSight ELA-600 provides a superset of the functionality of the ELA-500. The largest functional additions are acquiring trace data over the Advanced Trace Bus (ATB) and having potentially eight Trigger States instead of five.

Find more documented information about the ELA-600 in the Resources section of this tutorial.

The problem

Memory data corruption occurs when on-chip operations like unintended code execution or stack or heap leakage or externally like through malicious code. So, it is useful to have a way to monitor exactly what memory transactions are occurring for certain regions of memory and act accordingly.

In this tutorial scenario:

  • Memory accesses to a specific address (0xB1000000) are tracked three times.
  • The ELA-600 monitors the memory accesses and wait for any memory corruption to occur.
  • When memory corruption occurs, the ELA-600 sends a halt to the core through the Cross Trigger Interface (CTI).
  • The ELA-600 counts how many cycles occur between sending the halt request and the core sending a halt acknowledgment.

This scenario is modeled on the Data Corruption Scenario found in the Application Note - Arm CoreSight ELA-600 Version 1.0.

The solution

CoreSight ELA-600 is used in this scenario to trace the external bus transactions made by the processor. This tutorial shows the use case scripting capabilities of Arm Development Studio (Arm DS). It also demonstrates the example CoreSight ELA-600 DTSL use case scripts shipped with Arm DS.

About the CoreSight ELA-600

ELA-600 implementations can have up to 12 Signal Groups. Each Signal Group can contain 64, 128, or 256 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 target or implementation documentation. Low-level signal description documents are typically not publicly available. These documents are only made available to licensees of the Arm IP.

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 the IP using Arm DS and the ELA. An example of a JSON file can be found in the Arm DS ELA-600 deliverables, <Arm DS installation directory>\examples\\DTSLELA-600\axi_interconnect_mapping.json.

Signals typically consist of debug signals like status or output and qualifiers like triggers. Use qualifier signals to determine if the debug signal is valid. Debug signals are valid when the qualifier signal or signals are asserted.

The system

For the purposes of this tutorial, we use an example Cortex-A55 + ELA-600 + CCI-500 system. The system exposes several pre-defined debug observation ports known as Signal Groups. Arm DS provides the system JSON signal-mapping file.

CCI-500 Partition P1 is connected to Signal Group 0 of the ELA-600. The following are the CCI-500 signals of interest in this case:

  • VALID_P1 at Signal Group 0 bit position 127.
  • Address_P1 at Signal Group 0 bit position 114:75.
  • Type_P1 at Signal Group 0 bit position 73.

These signals are required to determine the accesses issued by the core to locate the memory corruption. Post analysis of these read transactions allows tracking of:

  1. Three of the memory space transactions. The last transaction is the memory corruption.
  2. The counter value between the halt request and the halt request acknowledgment.