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:

An L2 snoop request that must be serviced
by the core L1 Data cache.

A cache or TLB maintenance operation that must be
serviced by the core L1 Instruction cache, data cache, or TLB.

An APB access to the debug or trace registers residing
in the core power domain.

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.