Debugging over powerdown

When using a debugger, you may have connected to or debugged when one or more cores on the target are powered down. Depending on the SoC design or core power state, you may have little or no debugging ability. In this section, we will discuss the architectural facets of debugging over power down, and what power domain separation on a DynamIQ Shared Unit (DSU) would look like. We will not discuss how the power states on the DSU are achieved.

Power down architecture information

The Armv8-A architecture implementations usually separate processor logic and processor debug logic into different power domains. Depending on the core power state, this could allow a debugger to continue debugging even when one or more cores are powered down.

The four architected core power states are:

  • Normal. The core power domain is fully powered up and the debug registers are accessible.
  • Standby. The core power domain is on, but there are measures to reduce energy consumption. In a typical implementation, the processor element (PE) enters standby by executing a WFI or WFE instruction, and exits on a wake-up event. The PE preserves the PE state and debug logic state. In standby, the PE is unavailable, and no debug settings are cleared. Receiving a debugger request or accessing the external debug interface will wake up the core from standby. A debugger will not be able to tell if the core is in standby, because standby is transparent. This means that standby is indistinguishable from normal operation.
  • Retention. The OS takes some measures to reduce energy consumption. The PE state, including debug settings, is preserved, which allows the core power domain to be at least partially turned off. The saved PE state is restored when it changes from retention state to normal operation. Debugger requests stay pending, and debug registers in the core power domain cannot be accessed. This means that debug capabilities will be very limited when a core is in retention state.
  • Powerdown. The OS takes some measures to reduce energy consumption by turning the core power domain off. These measures must include the OS saving any PE state, including the debug settings, that must be preserved over powerdown. Changing from powerdown to normal operation must include:
    •  A Cold reset of the PE after the power level has been restored.
    • The OS restoring the saved PE state.
    • Debug events stay pending, and debug registers in the core power domain cannot be accessed. This means that the debugger will probably only be able to access the debug logic if it is a different power domain to the core. This is because no interaction with the powered-down core is possible.
    • OS threads will appear in the debugger as powered off or held in reset state.
Designs with DynamIQ Shared Units

If your SoC design uses DynamicIQ clusters with their accompanying DSUs, the DSU allows for the core-associated logic to be in a separate power domain to the debug logic in the DebugBlock. The following diagram illustrates the possible power domain divide between the core and DSU logic and the DSU DebugBlock:

This image shows the possible power domain divide between the core and the DSU logic and the DSU Debug Block 

The separate power domains allow the cores and the cluster to be powered down, at the same time maintaining essential state that is required to continue debugging. We saw that different power states result in different types of debugging experiences.

Previous Next