Main menu
You are here
Power Consumption Modeling for Electronics
Complex hardware designs and sophisticated usage profiles (or behavior) can make estimating battery life or choosing the correct battery for your design a challenge.
This article briefly explains how such a system can be modeled.
The basic premise is that complex behavior can be modeled using explicit configuration of hardware, a fixed number of code pathways, explicit usage profiles and average power consumption.
We will see that total energy consumption can be calculated by using a straight forward discrete calculus of blocks of Σ current x time and Σ (current x time) x voltage.
An assumption here is that components are typically held in reset until needed. The power consumption of the devices in use as well as leakage paths (including hardware in reset or power gated) is all tracked.
There is also a strong focus on daily energy consumption. So it is important to articulate the behavior of a device over a period of one day (although I'm sure it could be adapted to any period of time).
The following entities are used in the model. Each feeds into the next in a hierarchy.
| Component | Unit | Description |
| System Profiles | mWh/charge | Total system performance would be profiled here. This is considered a superset of usage profiles, although some devices the usage profile is the only behavior so the system profile is the usage profile. However some devices have behavior change based on battery capacity (e.g. low power mode when the battery dips beneath a threshold). Other devices need to accommodate multiple systems running in parallel. The power consumption from each system module would be summed here. |
| Battery Profiles | Wh/charge | Batteries are profiled here for things like capacity and also derating factors. This information is used by the system profiles to estimate run-times. |
| Usage Profiles | Wh/day | Daily energy consumption of a specific set of behaviors is calculated here by tallying the number of times an event triggers multiplied by the energy per event. The energy for all events in a day is summed. |
| Event Rollups | Wh/event | Here total energy consumption is calculated for each event profiled in the functional breakdowns. This is total system energy consumption, so think of this as the devices out of reset (profiled in the breakdowns) plus all leakage paths (including the leakage of devices held in reset). This is the first place we see energy as the unit. |
| Power Trees | N/A | Power supplies assembled into trees by identifying connectivity. Power domains (or power supply gating) should be identified here as well. This information is usage by the event rollups. |
| Power Supplies | N/A | Power supply properties, notably efficiency calculations. This is not about designing a power supply, focus should be on energy efficiency, heat loss, etc. This information is usage by the event rollups to estimate power supply efficiency during a specific task. |
| Functional Breakdowns | Amp-seconds | This is where code pathways are broken down. Each code pathway is reduced to a discrete number of steps, each is identified with the hardware that is being used along with the configuration of each device at each step. Each step has a specific length of time. |
| Component Profiles | Amps | The only thing we are interested here is current. Components are tied to rails elsewhere. Here we identify current consumption for specific configurations. For example an MCU can be configured practically an infinite number of ways, each with its own current consumption. It is key to identify the specific number of configurations needed for the design and to profile the current consumption for each. |
Using this structure will result in a fairly accurate model. I'd say it is easy to hit a target that is within 10%, possibly even better but it takes time and investment to model or measure everything here. Devices with many components, power states, usage profiles, etc can be very time consuming. I will say that once you set up the template most of it does not change.
- Log in to post comments