Reducing Power Consumption | Early System-Level Modeling

admin_mirabilis

Measuring and Reducing Power Consumption Using Early System-Level Power Modeling

Power evaluation in the early stages of the product design has been performed mostly using analytical methods such as spreadsheets. These spreadsheets typically contain the power for different tasks or devices and the sheet adds the worst case or the average of the power.  These methods provide some insight but they fail to capture the concurrent nature of the power consumption.  Moreover, these models are evaluated in isolation, and do not incorporate the task timing, and cover the entire design space of use cases.

Power management is a critical design factor in electronics.  Product features of consumer applications, space-based systems, data center solutions, and high-performance computing are constrained by the power budget. The reasons are customer demand, the weight of the Lithium-Ion batteries and the physical space to install the solar panels.  The efficiency of the application task graph on the target hardware resource determines the energy consumption and dictates battery selection, energy harvesting and additional power management. 

Power must be looked at from a holistic view of the power consumption of electronics, displays, electric and MEMS technologies; battery and other energy storage; and harvesters such as motors and solar panels.  At the system-level, energy usage is determined by user-cases, the number of starts and duration of each run, the power states of complex electronics, the state-machine to change state based on activity or inactivity and the power minimization algorithm.  In the battery, it is about the lifecycle which is impacted by request spikes, charging rates, thermal and physical shocks and attributes of each battery family. The energy harvesting takes in to considerations factors such as correct angle or coils, availability of the source such as Sun rays, nuclear material, and spikes in the requirements.

Over the years, a number of power management algorithms have been proposed.  Over time, these algorithms have become ingrained, and their limitations have been exposed. As a result, these algorithms have been evolved with constraints or replaced with software-based power management.  The smaller semiconductor process node size has increased the leakage power, larger processors have increased thermal insulation requirements, and the increased number of high bandwidth sensors has created the need for a higher drag during shorter durations.  Power can also be impacted by the reduction in data movement, the distribution of software tasks, task scheduling, and the selection of alternate topologies.

Experiments on three selected examples

Let us take a couple of simple examples and look at the impact on power by various architecture decisions.  The examples are of hybrid vehicle, Cubesat, and a multi-core System-on-Chip or processor.

Hybrid Vehicle

In Hybrid vehicles, we look at the energy generated by the motor that charges the battery and provides power to all nodes in the system.  The block diagram of the system simulation in VisualSim is shown in Figure 1. For a particular configuration, the generated reports are captured in Figure 2.  As you can see from the total power plot, the peak power is requested for a very short duration of time.  You can also see which devices are activated concurrently and which devices are rarely or randomly turned on.  This power profile provides visibility into periods of low power activity, opportunities to disable devices or networks, and size the battery.

Figure 1: Block Diagram of a system-level power model of a Hybrid SUV in VisualSim
Figure 2: Power profile for the Hybrid SUV model in VisualSim

CubeSat

The second design is a CubeSat system that is made up of multiple sub-systems and receives power from a Photo-Voltaic Cell.  The design incorporates the behavior of the satellite during direct Sun view and during an eclipse.  The use-cases are defined on a per-orbit and the processing takes into consideration the time of the day, number of tasks enabled, sub-system active during each task and duration of the activity.  The processing devices are set to lower speeds during discharge and are at full performance during charging periods.  Figure 3 shows the block diagram of the CubeSat which contains four parts- Task Graph of the use cases per orbit; Battery and photo voltaic cells; sub-systems and their connectivity to the Bus and the Scheduler. Figure 4 shows the average and instant power across 10,000 orbits, the activity of the sub-systems based on the number of active tasks, and the power details for each sub-system.

Figure 3: Block Diagram of a Cubesat in VisualSim to evaluate the power, timing deadlines and task-to-system allocation
Figure 4: Power and activity views of a CubeSat architecture exploration model

Multi-core SoC

The last example is of a multi-core System-on-Chip with a custom dispatcher as opposed to a Real-Time Operating System. There are four threads running concurrently with different processing times.  In this example, we evaluate the impact of scheduling tasks as they arrive vs providing offsets.  The evaluation metric is the increased latency vs lower power consumption.  Figure 5 shows the simulation results of the multi-core architecture for the power and latency with no offset of the tasks.  As you can see, all four cores are in use.  Figure 6 show the similar plots with an offset of 35.0 microseconds between the concurrent tasks. You can see how the latency is not impacted at all but the number of active cores has reduced to two. We reduce both cost and power consumption.  If the requirements can handle the extra delay, a much better solution is available.

Figure 5: Multi-core architecture model with no offset between concurrent tasks
Figure 6: Power, Latency and Activity Diagram of a Multi-core architecture with small offsets between concurrent tasks.

All the analysis in the above examples was carried out using VisualSim from Mirabilis Design.  VisualSim Architect is a graphical modeling and simulation for the exploration of architecture of electronics and semiconductors.  We used the pre-built libraries and standard reports from VisualSim for our design analysis.  The modeling environment allowed us to capture the timing and power consumption of the electronics, electric sub-systems and MEMS.  As a result, we could get a global view of the full system. The multi-core architecture used a quad-core cycle-accurate model of an ARM Cortex A53. We selected the A53 because of the wide-spread availability of System-on-chips (SoC) from processor vendors and the FPGA vendors have incorporated it into their new generation of MPSoC FPGAs. All three models were constructed and evaluated in about two weeks. 

Conclusion

System-level modeling can be used to measure the power consumption at the beginning of the project.  Models must incorporate the timing, power and functionality of all the sub-systems into the architecture model. This ensures that you can view the interaction between the different parts of the system and also see how you gain advantages by sharing resources, while not forgoing any performance. To evaluate the real-benefit of system modeling, we ran the tests across large systems, embedded architectures, and semiconductors.  We found that the same methodology can be applied to these segments even though the evaluation may be different.  VisualSim Architect had the libraries for all these application segments, and this allowed us to speed up the model development.