summaryrefslogtreecommitdiff
path: root/src/doc/power_thermal_model.doxygen
diff options
context:
space:
mode:
Diffstat (limited to 'src/doc/power_thermal_model.doxygen')
-rw-r--r--src/doc/power_thermal_model.doxygen128
1 files changed, 0 insertions, 128 deletions
diff --git a/src/doc/power_thermal_model.doxygen b/src/doc/power_thermal_model.doxygen
deleted file mode 100644
index 8b636ab23..000000000
--- a/src/doc/power_thermal_model.doxygen
+++ /dev/null
@@ -1,128 +0,0 @@
-# Copyright (c) 2016 ARM Limited
-# All rights reserved
-#
-# The license below extends only to copyright in the software and shall
-# not be construed as granting a license to any other intellectual
-# property including but not limited to intellectual property relating
-# to a hardware implementation of the functionality of the software
-# licensed hereunder. You may use the software subject to the license
-# terms below provided that you ensure that this notice is replicated
-# unmodified and in its entirety in all distributions of the software,
-# modified or unmodified, in source code or in binary form.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are
-# met: redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer;
-# redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in the
-# documentation and/or other materials provided with the distribution;
-# neither the name of the copyright holders nor the names of its
-# contributors may be used to endorse or promote products derived from
-# this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-#
-# Author: David Guillen Fandos
-
-/*! \page gem5PowerModel Gem5 Power & Thermal model
-
- \tableofcontents
-
- This document gives an overview of the power and thermal modelling
- infrastructure in Gem5. The purpose is to give a high level view of
- all the pieces involved and how they interact with each other and
- the simulator.
-
- \section gem5_PM_CD Class overview
-
- Classes involved in the power model are:
-
- - PowerModel: Represents a power model for a hardware component.
-
- - PowerModelState: Represents a power model for a hardware component
- in a certain power state. It is an abstract class that defines an
- interface that must be implemented for each model.
-
- - MathExprPowerModel: Simple implementation of PowerModelState that
- assumes that power can be modeled using a simple power
-
- Classes involved in the thermal model are:
-
- - ThermalModel: Contains the system thermal model logic and state.
- It performs the power query and temperature update. It also enables
- gem5 to query for temperature (for OS reporting).
-
- - ThermalDomain: Represents an entity that generates heat. It's
- essentially a group of SimObjects grouped under a SubSystem component
- that have its own thermal behaviour.
-
- - ThermalNode: Represents a node in the thermal circuital equivalent.
- The node has a temperature and interacts with other nodes through
- connections (thermal resistors and capacitors).
-
- - ThermalReference: Temperature reference for the thermal model
- (essentially a thermal node with a fixed temperature), can be used
- to model air or any other constant temperature domains.
-
- - ThermalEntity: A thermal component that connects two thermal nodes
- and models a thermal impedance between them. This class is just an
- abstract interface.
-
- - ThermalResistor: Implements ThermalEntity to model a thermal resistance
- between the two nodes it connects. Thermal resistances model the
- capacity of a material to transfer heat (units in K/W).
-
- - ThermalCapacitor. Implements ThermalEntity to model a thermal
- capacitance. Thermal capacitors are used to model material's thermal
- capacitance, this is, the ability to change a certain material
- temperature (units in J/K).
-
- \section gem5_thermal Thermal model
-
- The thermal model works by creating a circuital equivalent of the
- simulated platform. Each node in the circuit has a temperature (as
- voltage equivalent) and power flows between nodes (as current in a
- circuit).
-
- To build this equivalent temperature model the platform is required
- to group the power actors (any component that has a power model)
- under SubSystems and attach ThermalDomains to those subsystems.
- Other components might also be created (like ThermalReferences) and
- connected all together by creating thermal entities (capacitors and
- resistors).
-
- Last step to conclude the thermal model is to create the ThermalModel
- instance itself and attach all the instances used to it, so it can
- properly update them at runtime. Only one thermal model instance is
- supported right now and it will automatically report temperature when
- appropriate (ie. platform sensor devices).
-
- \section gem5_power Power model
-
- Every ClockedObject has a power model associated. If this power model is
- non-null power will be calculated at every stats dump (although it might
- be possible to force power evaluation at any other point, if the power
- model uses the stats, it is a good idea to keep both events in sync).
- The definition of a power model is quite vague in the sense that it is
- as flexible as users want it to be. The only enforced contraints so far
- is the fact that a power model has several power state models, one for
- each possible power state for that hardware block. When it comes to compute
- power consumption the power is just the weighted average of each power model.
-
- A power state model is essentially an interface that allows us to define two
- power functions for dynamic and static. As an example implementation a class
- called MathExprPowerModel has been provided. This implementation allows the
- user to define a power model as an equation involving several statistics.
- There's also some automatic (or "magic") variables such as "temp", which
- reports temperature.