|Non-Confidential||PDF version||ARM 100241_0001_00_en|
|Home > Functional Description > Power Management > 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
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.
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.