The modules such as ETM, HTM, STM monitor ARM processor and AMBA bus activities and log trace data into some memory which can be read out offline or directly to pads for real-time or post processing.
It is intuitive to think CoreSight can be expanded to monitor other hardware modules and log their activities. Indeed, this idea is not new and has been implemented in many commercial SoCs. As a matter of fact, there is a company, named UltraSoC, provides this kind of debugging and tracing IPs.
The KEY idea of UltraSoC solution is to convert hardware trace into messages and route messages through message routing network and eventually into memory or to transport such as GPIO, JTAG, USB, etc. This message based tracing is exactly what CoreSight does.
Brief description of their IPs:
Bus performance monitor with trace
Passively monitors a master or slave interface on a bus, point-to-point fabric or on-chip network such as AXI, AXI4, or OCP 2.1. Also supports coherent protocols such as ACE and OCP 3.0 and packet-based interfaces like AMBA 5 CHI, and is easily adaptable to proprietary interconnects. Sophisticated filtering allows monitoring of end-to-end metrics such as bus cycles, transactions, duration, latency and hesitancy. Also allows debugging of bus hangs and error transactions.
A parametrized module that enables a wide variety of monitoring functions, including event and message generation, counting, accumulating and data trace, in response to system states or other conditions or sequences.
Processor advanced modules
Interfaces to processors and their proprietary debug resources (e.g. CoreSight). There are variants for ARM cores (including Cortex-A, -R, and -M), Cadence (Tensilica XTensa) and MIPS processors, allowing access to standard features such as run-control, breakpoint and watch-point resources, cross-triggering, and performance monitoring (eg cache hits). The module can be collocated and directly coupled with a processor or group to offload debug communication from the proprietary debug-interconnect and allow a truly scalable debug solution. Alternatively it can be indirectly coupled using an existing infrastructure such as ARM’s CoreSight.
Software instrumentation module
Allows data delivered over a bus fabric such as AXI to be automatically converted to UltraDebug instrumentation trace messages and transferred to the host debugger. The typical use case is to collect trace data from user APIs such as those from an OS. Supports time-stamping and cross-triggering with other modules.
Virtual console module
A peripheral interface that enables the system software to communicate bi-directionally with the debug host (generally running third-party development tools) via UltraSoC.
Debug DMA module
Provides memory access, enabling the debugger to read or write a block of memory via a bus fabric such as AXI, APB or OCP, in response to UltraSoC messages or events when preconfigured with a transfer description.
JTAG master module
Allows control of the IEEE1149.1 JTAG TAP from UltraSoC messages instead of from chip pins. Can be used to access and control IP components that are limited to access over JTAG, and enable power-on-self-test and other scan-based debug activities
System memory buffer module
Allows storage of debug messages in system memory using a bus interface like AXI.
Utility (GPIO) module
Connectivity module allowing the conversion of events into I/O signals that can be used internally or wired to chip I/O pins to enable interaction with external tools such as oscilloscopes.
Drives UltraSoC messages into an alternative debug system’s trace funnel for export to an external parallel port or high-speed serial interface. Versions are available for ARM’s CoreSight (ATB Communicator), MIPS’s PDTrace (MPDT Communicator), external parallel port interfaces, in-house trace solutions or AXI4 streaming interface.
Internal bus communicator
Enables software running inside the chip to actively drive UltraSoC through a bus slave as though it were the host debugger, allowing the software to “monitor itself” during pre-deployment testing and post-deployment / early-adoption.
Message engine and message hub modules
Universal blocks that can be connected hierarchically to form an on-chip debug fabric with a tree topology based on the UltraSoC message interface. Prioritize and route messages and real-time events between their interfaces and provide optional features such as buffering and shared security services.
A non-blocking message-based interconnect for joining the debug hierarchies of multiple sub-systems into a large-scale system in a variety of topologies (e.g. a ring). This is especially useful in larger SoCs, and with sub-systems in different power domains or clock domains.
Message slice module
Used to break the combinatorial path between one message interface and another by registering the signals in each direction. Aids timing closure by breaking a long link into two shorter links.
Provides debugger connectivity to UltraSoC via an IEEE 1149.1 scan-test interface.
Connects directly to an on-chip USB PHY to enable interconnection with the debug host at a much higher speed than would be possible using a traditional serial interface. Autonomous, requiring no host processor or software intervention. Optionally there is a hub component enabling the system to simultaneously use the same physical interface without processor intervention.
Overall, this solution can not only be used for hardware debugging, but also for performance profiling and security/intrusion monitoring.
Although the solution tends to be non-intrusive, it can be enhanced to alter SoC operation if desired. For example, when security issue is detected, it can freeze part of chip operation, assert trap to firmware, or even assert a reset.