The SoC debug framework implements the Power-AP module to provide:
- A method for the debug tooling to query the power, reset and/or clock status of the system and any independent subdomains within the system. This allows the tooling to understand if the current state of a system or subdomain will support an active debug connection
- A method for the debug tooling to request changes in system functionality that might override the current functional states of power/reset/clock (for example, preventing power/clock down while actively debugging a target in a dynamically powered domain)
- Capability to hold the entire device or a subsystem within the device in reset until the debug tools can attach. This provides developers a method for debugging subsystems as they transition out of reset (wait-in-reset operation)
- Control for synchronously requesting execution state changes for cores in multiple subdomains. This allows the debug tooling to synchronously halt, step and run a set of cores in a multiple core system. In addition, an interface is provided that reflects the execution state of those cores without requiring an active debug connection to that core. Using this, the debug tooling can remotely monitor and control a subdomain while it transitions through all the normal power/clock/reset functional modes
The Power-AP interfaces with various modules in the system that include:
- Chip-level power/clock/reset control logic
- Debug logic in CPU cores in the managed subdomains
- Chip-level triggering architecture
Ports on the Power-AP and DEBUGSS exist for each
debug target in the system. Status and control signals from these ports are
integrated with the debug target (usually an individual CPU) and the PSC/LPSC that
is managing the subdomain with that CPU. These are generally logical subdomains as
LPSC/PSC can manage power for multiple cores.