From be28d96510e0e722db83b26f1a12d3f5de979b32 Mon Sep 17 00:00:00 2001 From: Andreas Sandberg <andreas.sandberg@arm.com> Date: Wed, 6 Apr 2016 19:43:31 +0100 Subject: Revert power patch sets with unexpected interactions The following patches had unexpected interactions with the current upstream code and have been reverted for now: e07fd01651f3: power: Add support for power models 831c7f2f9e39: power: Low-power idle power state for idle CPUs 4f749e00b667: power: Add power states to ClockedObject Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> --HG-- extra : amend_source : 0b6fb073c6bbc24be533ec431eb51fbf1b269508 --- src/doc/power_thermal_model.doxygen | 128 ------------------------------------ 1 file changed, 128 deletions(-) delete mode 100644 src/doc/power_thermal_model.doxygen (limited to 'src/doc/power_thermal_model.doxygen') 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. -- cgit v1.2.3