We
can control:
-
Processor core clock speed
and voltage (ARM
SA-1100)
-
FPGA external clock (Xilinx
XC4020XL)
-
Radio power and operating
mode (Bluetooth)
Bluetooth
controls are routed
through the Xilinx so that they can be manipulated from the ARM or the Xilinx,
or both. ARM wake from idle is
any interrupt source, and ARM wake from sleep are one or more predefined
interrupt sources.
In
the current implementation, there is a common 3.3v supply for both the ARM and
Xilinx, so the Xilinx cannot be powered down separately. The Bluetooth can be powered down
independently. Off mode for the
ARM and Xilinx is board power off.
Xilinx sleep mode is established by turning off the
clock.
Test conditions:
Supply voltage (VBATT) =
7.200 measured at breakout board pins.
Current measured at supply.
ARM spinning in
the kernel idle loop, running from cache (Bluetooth.axf).
(experience shows that the ARM runs from cache most of the time in the
applications we run)
Xilinx running
the Bluetooth controller.
Summary:
The most effective
means of power control are changing the clock speed and core voltage (DVS) and
setting the radio operating mode:
Except in ARM
sleep mode, reduction of power consumption using DVS approaches a factor of
four. With the ARM in sleep mode there is very little difference
between DVS settings. However, there is also little difference between
ARM sleep and idle modes with DVS at minimum. The nodes were able to
run the sensoring application (basestation and remote) at minimum DVS with
no degradation.
Second to DVS is
radio operating mode. Receive takes a little more power than transmit;
idle and off are more-or-less equivalent. So, the best approach would
be to leave the radio in idle mode as much as possible.
Xilinx run/sleep
and ARM run/idle have measurable effects on power consumption but are much
less effective than DVS and radio mode. ARM run/idle will be on by
default in future projects, and will not require user control except via a
idle time constant. Radio control is via the Xilinx, so the radio is
effectively isolated with the Xilinx in idle mode. For this reason, it's
recommended that Xilinx power control be incorporated when the application is
fully debugged and ready for deployment.
The absolute
minimum power consumption (108mw) occurs at the obvious point: ARM sleep,
Xilinx idle, radio off (aka deep sleep). The next highest point (130mw)
occurs three times, all at 60MHz/0.925v: twice in ARM sleep mode and once in
ARM idle mode. Considering the complexity involved with setting up and
recovering from ARM sleep it appears that the optimal operating point for low
power consumption is ARM idle, Xilinx sleep, and Radio off. If ARM idle
mode is used by default (a kernel service) and the user does not take
advantage of any other power control capability (other than idling the radio
when not in use), the operating point for minimum power consumption (194mw) is
ARM idle, Xilinx run, radio idle.
typical operating point
minimum
operating point
maximum
minimum
Raw
Measurements
Summary:
-
Numbers for
the radio are fairly accurate. It's obviously of great benefit to
keep the radio in idle mode whenever possible i.e. don't leave the
receiver turned on by default. It would be useful to establish the
contribution to the baseline for the 'off' state, since the Bluetooth
board power supply is not completely shutting down.
-
Numbers for
the ARM are close. The primary message here is that DVS is of great
benefit, and the ARM should be run at as low a DVS setting as
possible. There are two concerns remaining:
-
Typically,
there are variations in sleep mode power consumption due to
differences in pin sleep state between applications. ARM
contributions to the baseline will vary depending on pin sleep state;
no special effort was made to analyze the effect of a change in this
condition.
-
It seems
like the deltas in low DVS mode from sleep to idle and sleep to run
should be greater i.e. there should be SOME difference between sleep
and idle in any case. Clearly, the contribution to baseline is
substantial if the difference between sleep and run is 7mw. Or,
the ARM is truly a low power chip!
-
Numbers for
the Xilinx are suspect for two reasons:
-
If sleep
state is considered to be almost off (static CMOS with no clock), then
run state should take more than 65mw. Either sleep state is not
correctly implemented, there is more leakage than expected, or the
power consumption in run mode is less than expected given the
application in use.
-
The
Xilinx is apparently not able to stay in run mode when the ARM sleeps,
so, for instance, a Xilinx transition from sleep --> run with the
ARM sleeping is effectively sleep --> sleep. This can be
fixed by paying closer attention to the ARM GPIO sleep state.
With the ARM and
Xilinx in sleep mode and the radio off, there is a baseline power consumption
somewhere around 100mw. There is a contribution to this from the ARM but
the amount is unknown. It's probable that the Xilinx contributes a fair
amount, suggested by the low relative difference from baseline between sleep
and run modes (65mw). The Bluetooth power supply is also not shutting
off properly (not 0 volts), so the radio board is probably contributing a
small amount (very small) as well. For the purposes of analysis at this time,
we'll attribute this baseline to remaining devices in the system e.g. SRAM,
flash, LEDs, crystals, and logic chips.
Contributions for
each component are measured in terms of the difference between the baseline
values and some non-baseline condition. An example: for any given
condition for the ARM and Xilinx the contribution of the radio is computed by
taking the difference of idle and off, Rx and off, and Tx and off . In
most cased changing the condition of one subsystem does not affect the
condition of a different subsystem e.g. radio deltas with ARM sleeping, idling
or running are the same. This is indicated by the Any designation in the
table cells below.
There are some
inconsistencies in the data as shown by the red text in the table. All
but one can be explained if the Xilinx is sleeping rather than running with
the ARM in sleep state. This is possible since the Xilinx oscillator is
controlled by an ARM GPIO pin, and no special measures were taken to ensure
this pin stayed in a particular state. The unexplained inconsistency has
the same basic signature as the others, but the delta value is lower than
expected. It's probably worth the time to explore conditions in the
Xilinx in more detail; sleep mode predictability, control of internal state
during sleep, etc.
The most
interesting result is the very small difference between all three ARM modes
when running at low core voltage and clock speed. This reinforces the
idea that ARM sleep mode may not be worth the trouble. One caveat: the
ARM load was small in these tests, so it may be useful to incorporate at least
idle mode in more complex applications.