With the advent of the Internet of Things (IoT), tiny, low-cost devices are becoming ubiquitous. New applications that bridge the cyber and physical world to improve healthcare, logistics, infrastructure, smart buildings, and more, are driving a need for increasingly smaller and lower-cost devices.
Two years ago at Arm TechCon (now DevSummit), Arm Research Fellow Rob Aitken discussed How to Build A Trillion Connected Things on Arm Community. He demonstrated that a trillion devices, if powered by lithium coin cell batteries, would contain three times the world's annual production of lithium. He suggested energy harvesting as a potential solution to this monumental economic and environmental challenge. This would enable us to augment, or even replace, battery power with energy harvested from ambient solar, mechanical (wind, vibration, motion), radiofrequency, or thermal energy sources.
But harvested energy can often be scarce, dynamic, and unpredictable. Look at the power output of a solar cell in Figure 1, for example. It can exhibit significant short-and long-term variations, depending on unpredictable external factors such as weather, location, dirt settling on its surface, and nearby stationary or moving objects, to name a few.
Figure 1: Power output trace of a 250 cm2 outdoor solar cell over course of 24 hours, reprinted from [2]
This blog post presents some background of energy-driven and intermittent computing, before introducing our SystemC-based simulator for such systems. The project is a collaboration under the Arm-ECS Research Centre, and is based on the paper recently presented at ISPASS 2020 [4]. A video of the presentation is also available here.
Learn more about the Arm-ECS collaboration, and the topics our sponsored PhD students are investigating.
To ensure reliability over decades of deployment, the dynamic availability of energy must be considered as a fundamental component throughout the system and application design process. The operation of these energy-driven computers [1] is often governed by energy availability. They continuously adapt their operation to deliver the highest possible quality of service for the energy available during deployment.
One example of an energy-driven mode of operation is energy-neutral operation. This is where systems adapt their energy consumption to match harvested energy over long periods, using moderate amounts of energy buffering in the form of rechargeable batteries or supercapacitors. While this alleviates some of the battery capacity issues, this approach is still too dependent on energy storage to be scalable to a trillion devices.
Another example is intermittent operation, where the system retains computational progress despite frequent power outages. They can do this, for example, by saving checkpoints in non-volatile memory when an imminent power failure is detected; the next time power returns, they can continue from the latest checkpoint.
The oscilloscope recording in Figure 2 shows a charge-compute-discharge cycle which is typical of an intermittent system. After sufficient charging, the microcontroller turns on, Restores, and then resumes execution (Compute). Before the supply voltage drops too low, the microcontroller Suspends context to non-volatile memory (so that it can continue where it left off the next time energy is available). Critically, the Suspend operation must finish before brownout, that is, before the supply voltage drops below the dashed line. If Suspend does not finish in time, the checkpoint will most likely be corrupt.
Figure 2: Oscilloscope trace showing a typical power cycle of an intermittent computing device, reprinted from [3]
Under intermittent operation, systems opportunistically make progress whenever energy happens to be available. These systems operate correctly on unstable power supplies, while requiring minimal energy buffering (a tiny ceramic capacitor suffices), so devices can be made to be exceptionally tiny and low-cost. However, developing hardware and software for intermittent operation requires careful consideration of the interactions between energy and execution.
Reasoning about energy-driven computers is complicated, due to the complex relationships between energy availability, energy consumption, and adaptive execution. For continuously powered "always-on" devices, you may simulate execution first, and then feed the results into a power estimation tool to obtain the energy consumption. For energy-driven computers however, execution, energy availability and energy consumption must be modeled simultaneously in a closed feedback loop. This is because they all affect each other in real time.
To address this challenge, we have developed an open source full-system simulator for energy-driven computers called Fused [4]. An overview is illustrated in Figure 3.
Figure 3: Fused’s closed-loop model of energy and execution
Fused models execution, power consumption, and power supply in a closed feedback loop to correctly model the interactions between them. Starting with the main feedback loop on the right, we take a high-level execution model and use it to generate events and module-states. We then feed that into a power model which calculates the instantaneous power consumption. The energy storage model (typically modelling a small capacitor) then calculates the supply voltage based on power consumption and supply. Under intermittent operation, the execution model is in turn affected by the supply voltage, which it monitors to trigger restore and suspend operations.
In addition to the main feedback loop, there is one on the power supply as well (on the left). This is used in order to model the energy harvester's dependency on the stored voltage, enabling accurate modelling of the current-voltage curve of tiny solar panels.
Fused targets energy-driven embedded systems, and employs SystemC for digital and mixed-signal simulation to model a microcontroller and mixed-signal circuitry, enabling hardware-software codesign and design space exploration. Fused also hosts a GDB server, so we can debug software through power cycles. This enables us to step through code in lockstep with the energy-environment (energy storage, power management, etc.). In that way, we can make sure that checkpoints are correctly saved in time before brownout. We can also hook up the execution model to energy harvesting models. This is to see how our methods perform under various conditions without needing to conduct costly and time-consuming experiments, which require deployment in the field during the early design process.
To demonstrate what Fused enables, we simulated an intermittent computing device running an AES encryption workload while powered by a 200 μA current source. On the bottom of the graph shown in Figure 4, you can see analog signals. That is the capacitor voltage in orange, the microcontroller's supply voltage in blue, and the instantaneous current consumption of the microcontroller in black. On the top, you have IO signals that indicate what the target application is doing, i.e. when it's active, restoring, suspending, and when an iteration of the workload begins.
Figure 4: Simulation trace from Fused, demonstrating intermittent computing on a 200 µA current source, reprinted from [4]
With this capability, we can identify key variables, such as charging time, active time, how long it takes to complete a workload, how much energy is spent on suspending state, and much more. And because such a simulation takes on the order of a minute to complete, this enables rapid debug and optimization cycles for both software and hardware prototyping.
While there are many technical and economical challenges in reaching a trillion connected devices, this post has introduced some of the progress we have made towards enabling efficient development of these devices at the system level. We hope this tool is useful to fellow researchers looking to test out new ideas, or evaluate the effect of improvements in particular components (for example, energy harvesting modules, power conversion, energy management, and so on), accelerating the proliferation of tiny connected smart devices.
Fused is an ongoing open-source project, so we encourage interested readers to check out the up- to-date repository on GitHub, and to contribute to the project. For more details on Fused, read the paper, or watch the video presentation.
Watch the Full Presentation
[1] Sliper, Sivert T., Oktay Cetinkaya, Alex S. Weddell, Bashir Al-Hashimi, and Geoff V. Merrett. ‘Energy- Driven Computing’. Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences 378, no. 2164 (7 February 2020): 20190158.
[2] Fletcher, Benjamin J., Domenico Balsamo, and Geoff V. Merrett. ‘Power Neutral Performance Scaling for Energy Harvesting MP-SoCs’. In Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017, 1516–21. Lausanne, Switzerland: IEEE, 2017.
[3] Sliper, Sivert T., Domenico Balsamo, Nikos Nikoleris, William Wang, Alex S. Weddell, and Geoff V. Merrett. ‘Efficient State Retention Through Paged Memory Management for Reactive Transient Computing’. In Proceedings of the 56th Annual Design Automation Conference 2019, 26:1–26:6. DAC ’19. New York, NY, USA: ACM, 2019.
[4] Sliper, Sivert T., William Wang, Nikos Nikoleris, Alex S. Weddell, and Geoff V. Merrett. ‘Fused: Closed- Loop Performance and Energy Simulation of Embedded Systems’. In Proceedings of the 2020 IEEE International Symposium on Performance Analysis of Systems and Software. Boston, MA, USA: IEEE, 2020.