power_thermal_model.doxygen revision 12678 
1# Copyright (c) 2016 ARM Limited
2# All rights reserved
3#
4# The license below extends only to copyright in the software and shall
5# not be construed as granting a license to any other intellectual
6# property including but not limited to intellectual property relating
7# to a hardware implementation of the functionality of the software
8# licensed hereunder.  You may use the software subject to the license
9# terms below provided that you ensure that this notice is replicated
10# unmodified and in its entirety in all distributions of the software,
11# modified or unmodified, in source code or in binary form.
12#
13# Redistribution and use in source and binary forms, with or without
14# modification, are permitted provided that the following conditions are
15# met: redistributions of source code must retain the above copyright
16# notice, this list of conditions and the following disclaimer;
17# redistributions in binary form must reproduce the above copyright
18# notice, this list of conditions and the following disclaimer in the
19# documentation and/or other materials provided with the distribution;
20# neither the name of the copyright holders nor the names of its
21# contributors may be used to endorse or promote products derived from
22# this software without specific prior written permission.
23#
24# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
25# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
26# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
27# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
28# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
29# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
30# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
31# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
32# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
33# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
34# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
35#
36# Author: David Guillen Fandos
37
38/*! \page gem5PowerModel Gem5 Power & Thermal model
39
40  \tableofcontents
41
42  This document gives an overview of the power and thermal modelling
43  infrastructure in Gem5. The purpose is to give a high level view of
44  all the pieces involved and how they interact with each other and
45  the simulator.
46
47  \section gem5_PM_CD Class overview
48
49  Classes involved in the power model are:
50
51    - PowerModel: Represents a power model for a hardware component.
52
53    - PowerModelState: Represents a power model for a hardware component
54      in a certain power state. It is an abstract class that defines an
55      interface that must be implemented for each model.
56
57    - MathExprPowerModel: Simple implementation of PowerModelState that
58      assumes that power can be modeled using a simple power
59
60  Classes involved in the thermal model are:
61
62    - ThermalModel: Contains the system thermal model logic and state.
63      It performs the power query and temperature update. It also enables
64      gem5 to query for temperature (for OS reporting).
65
66    - ThermalDomain: Represents an entity that generates heat. It's
67      essentially a group of SimObjects grouped under a SubSystem component
68      that have its own thermal behaviour.
69
70    - ThermalNode: Represents a node in the thermal circuital equivalent.
71      The node has a temperature and interacts with other nodes through
72      connections (thermal resistors and capacitors).
73
74    - ThermalReference: Temperature reference for the thermal model
75      (essentially a thermal node with a fixed temperature), can be used
76      to model air or any other constant temperature domains.
77
78    - ThermalEntity: A thermal component that connects two thermal nodes
79      and models a thermal impedance between them. This class is just an
80      abstract interface.
81
82    - ThermalResistor: Implements ThermalEntity to model a thermal resistance
83      between the two nodes it connects. Thermal resistances model the
84      capacity of a material to transfer heat (units in K/W).
85
86    - ThermalCapacitor. Implements ThermalEntity to model a thermal
87      capacitance. Thermal capacitors are used to model material's thermal
88      capacitance, this is, the ability to change a certain material
89      temperature (units in J/K).
90
91  \section gem5_thermal Thermal model
92
93  The thermal model works by creating a circuital equivalent of the
94  simulated platform. Each node in the circuit has a temperature (as
95  voltage equivalent) and power flows between nodes (as current in a
96  circuit).
97
98  To build this equivalent temperature model the platform is required
99  to group the power actors (any component that has a power model)
100  under SubSystems and attach ThermalDomains to those subsystems.
101  Other components might also be created (like ThermalReferences) and
102  connected all together by creating thermal entities (capacitors and
103  resistors).
104
105  Last step to conclude the thermal model is to create the ThermalModel
106  instance itself and attach all the instances used to it, so it can
107  properly update them at runtime. Only one thermal model instance is
108  supported right now and it will automatically report temperature when
109  appropriate (ie. platform sensor devices).
110
111  \section gem5_power Power model
112
113  Every ClockedObject has a power model associated. If this power model is
114  non-null power will be calculated at every stats dump (although it might
115  be possible to force power evaluation at any other point, if the power
116  model uses the stats, it is a good idea to keep both events in sync).
117  The definition of a power model is quite vague in the sense that it is
118  as flexible as users want it to be. The only enforced contraints so far
119  is the fact that a power model has several power state models, one for
120  each possible power state for that hardware block. When it comes to compute
121  power consumption the power is just the weighted average of each power model.
122
123  A power state model is essentially an interface that allows us to define two
124  power functions for dynamic and static. As an example implementation a class
125  called MathExprPowerModel has been provided. This implementation allows the
126  user to define a power model as an equation involving several statistics.
127  There's also some automatic (or "magic") variables such as "temp", which
128  reports temperature.
129*/
130