src/doc/power_thermal_model.doxygen

   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 */