A4.4 Core Wait for Event

A core can use the Wait for Event (WFE) instruction to cause the core to enter a low-power state.

Wait for Event (WFE) is a feature of the ARMv8-A architecture. It can be used by a locking mechanism based on events to put the core in a low-power state by disabling most of the clocks in the core while keeping the core powered-up. Apart from a small dynamic power overhead on the logic to enable the core to wake up from WFE low-power state, this reduces the power drawn to static leakage current only.

When executing the WFE instruction, the core waits for all instructions in the core to complete before entering the idle or low-power state.

If the event register is set, execution of a WFE instruction does not cause entry into standby state, but clears the event register.

While the core is in WFE low-power state, the clocks in the core are temporarily enabled without causing the core to exit WFE low-power state, when any of the following events are detected:

Exit from WFE low-power state occurs when the core detects a reset, the assertion of the EVENTI input signal, or one of the WFE wake-up events as described in the ARM® Architecture Reference Manual ARMv8, for ARMv8-A architecture profile.

On entry into WFE low-power state, STANDBYWFE for that core is asserted. Assertion of STANDBYWFE guarantees that the core is in idle and low-power state. STANDBYWFE continues to assert even if the clocks in the core are temporarily enabled because of an L2 snoop request, cache or TLB maintenance operation, or an APB access.

CLREXMON request and acknowledge signaling

When the CLREXMONREQ input is asserted, it signals the clearing of an external global exclusive monitor and acts as a WFE wake-up event to all the cores in the cluster.

The CLREXMONREQ signal has a corresponding CLREXMONACK response signal. This forms a standard 2-wire, 4-phase handshake that can be used to signal across the voltage and frequency boundary between the core and system.

The following figure shows the CLREXMON request and acknowledge handshake. When the request signal is asserted, it continues to assert until an acknowledge is received. When the request is deasserted, the acknowledge can then deassert.

Figure A4-2 CLREXMON request and acknowledge handshake
To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.

Non-ConfidentialPDF file icon PDF versionARM 100241_0001_00_en
Copyright © 2016, 2017 ARM Limited or its affiliates. All rights reserved.