Greater Debug of a SoC having heterogeneous ARM Core's

Mahesh Penugonda, Open-Silicon Research Private Limited
December 2014

Abstract:

In today’s world of smart and high end gadgets, devices serving variety of features is only made possible by having more than a single core. Having more than a single core results in rise of output performance and also giving a SoC with more features. SoC’s having mixed class of cores serving both worlds of low latency and high data processing requirements calls for greater visibility and debugging capability support built in.

This article is targeted for audience developing high performance and having mixed class of processors in a SoC. This article also can stand as a reference for devising a good non- invasive debug framework enabling faster software development and greater visibility of internal processor software flow and hardware interactions by using ARM Coresight.

This article describes a high visibility and non-invasive debug architecture having Quad Core ARM Cortex A9 and Dual Core ARM cortex R4 cores. This debug architecture implements ARM Coresight components to enable seamless debug capability and external trace support. ARM Coresight technology and the components are re-used for debug purposes in various SOC’s having ARM cores.

Introduction

With the ever growing demand of SoC’s in terms of performance and features, there are more challenges in terms of building an infrastructure to have debug capability non-invasively and also with greater visibility in to the chip. To meet these demands, there are various products in the market with more than a single core and being heterogeneous. This paper describes a SoC having more than a single core, the necessity to have debug infrastructure around the cores, how efficiently a verification suite is re-used to verify and get greater debug information of the SoC.

This paper has chapter 1 introducing a sample SoC, chapter 2 describing the requirements of debug, chapter 3 describing use of ARM Coresight/Debug technology, Chapter 4 describing a SoC with Coresight/Debug infrastructure, chapter 5 describing debug and trace capture schemes, chapter 6 verify debug architecture and Chapter 7 summary.

SoC with multiple and heterogeneous cores

Below diagram describes a SoC with two cores namely Core0_0 and Core1_0 of same family, Core1 and Core2 of different family cores and all cores are from ARM. All these cores are interfaced with peripherals via an interconnect. Each core described is designated to perform different functions.

Requirements of a debug and trace

In this SoC having multi core, it is necessary to have a debug infrastructure to be built in for reasons such as:

1. To debug and trace the code executing in cores when a deadlock situation arises due to conflict in accessing common peripherals.
2. To debug and trace the deadlock scenarios that might arise due to simultaneous access.
3. To debug non-invasively and trace the program execution flow in a core.
4. To have complete memory map view of the system bypassing the cores.
5. To set breakpoints, watchpoints, waypoints etc., non-invasively.

Coresight from ARM

Coresight from ARM is a debug and trace technology is an on-chip debug and real-time trace solution for a SoC having ARM processors. This technology from ARM makes debugging a SoCs a lot easier.

There are various coresight trace capture and trace sink components, triggering components and trace links. These set of products enable the debug and trace of the most complex, multi-core SoCs.

SoC with Debug infrastructure

In order to meet the mentioned requirements, a SoC with ARM Coresight components were integrated.

Following are the coresight components included in to the SoC

DAP – Debug Access Port: Has JTAG/Serial wire as debug interface. This debug interface has the necessary register interface inside DAP to map its read and write access instructions on to SoC via access interface. Various access interfaces are Debug APB, AHB, System APB are the means to connect to cores and rest of the SoC.

In this SoC, a JTAG instruction to initiate a transaction on AHB bus to access one of peripheral registers through interconnect is possible. This helps in accessing peripheral without having any of the cores involvement. This debug is selected when the transactions from core via interconnect to a peripherals are not working as required.

Each core is associated with its respective supported trace generator/source macrocells like PTM (Program Trace Macrocell), ETM (Embedded Trace Macrocell) etc. These macrocells are memory mapped and are accessed via Debug APB interface from DAP. These macrocells have necessary control interface with its core to start tracing the program executed on the core.

Components like Funnel acts as trace links to route multiple traces with a single trace output with a pre-determined priority order. Other components namely ETB (Embedded Trace Buffer), TPIU (Trace Port Interface Unit) act as trace sinks. These trace sinks get triggers from CTI on when to start capturing, trace flush, trace handshake mechanism.

Debug and trace schemes

With the mentioned debug architecture, following trace capture schemes can be adopted to get greater debug and visibility in to the SoC.

1. Via JTAG, program the PTM/ETM of respective core by setting breakpoints, waypoints etc. These macrocells start collecting the program data from its core for the set waypoints. Also the collected data is transferred on to trace link through which it gets stored in to ETB or exported to external trace analyser via TPIU.
2. If trace capture is not required and debugging by reading or writing to a register is of interest, it could be done through the AHB master interface of DAP which has full SoC memory map view.
3. Continuous trace captures of all the cores can be achieved through funnel in a weighted trace data being sent out of funnel to trace sinks.
4. Through system APB interface of DAP, cores could access DAP registers and initiate access to check other core registers.

Verifying Debug architecture

ARM Coresight verification suite was re-used to verify any debug architecture. This suite can also be customized to match with SoC debug architecture and verify trace generation, capture and triggers.

Conclusion

Integrating ARM Coresight components in to SoC gave lot of debug capability and greater visibility during situations when cores are not functioning as expected, isolating issues being independent on cores and trace capture capability.

References

• CoreSight Components Technical Reference Manual - ARM DDI 0314H
• ARM DSTREAM ARM DS-5 System and Interface Design Reference Version 5 - ARM DUI 0499H (ID092812)