derek/gem5
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

misc: Removed unneeded Doxygen pages

Browse Source 
These removed doxygen files have already been migrated to the gem5
website.

inside-minor.doxygen:
www.gem5.org/documentation/general_docs/cpu_models/minor_cpu

memory_system.doxygen:
www.gem5.org/documentation/general_docs/memory_system/gem5_memory_system

power_thermal_model.doxygen:
www.gem5.org/documentation/general_docs/thermal_model

Issue-on: https://gem5.atlassian.net/browse/GEM5-229
Change-Id: Ib36c364def2dae06a0efbedd3d398763ae7d4e21
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27487
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This commit is contained in:
Bobby R. Bruce
2020-04-03 14:45:28 -07:00
parent dd8870a251
commit 8be39b3059
3 changed files with 0 additions and 1496 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1089
src/doc/inside-minor.doxygen
View File

File diff suppressed because it is too large Load Diff

278
src/doc/memory_system.doxygen
View File

@@ -1,278 +0,0 @@
# Copyright (c) 2012 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: Djordje Kovacevic
/*! \page gem5MemorySystem Memory System in gem5
\tableofcontents
The document describes memory subsystem in gem5 with focus on program flow
during CPU’s simple memory transactions (read or write).
\section gem5_MS_MH MODEL HIERARCHY
Model that is used in this document consists of two out-of-order (O3)
ARM v7 CPUs with corresponding L1 data caches and Simple Memory. It is
created by running gem5 with the following parameters:
configs/example/fs.py --caches --cpu-type=arm_detailed --num-cpus=2
Gem5 uses Simulation Objects (SimObject) derived objects as basic blocks for
building memory system. They are connected via ports with established
master/slave hierarchy. Data flow is initiated on master port while the
response messages and snoop queries appear on the slave port. The following
figure shows the hierarchy of Simulation Objects used in this document:
\image html "gem5_MS_Fig1.PNG" "Simulation Object hierarchy of the model" width=3cm
\section gem5_CPU CPU
It is not in the scope of this document to describe O3 CPU model in details, so
here are only a few relevant notes about the model:
<b>Read access </b>is initiated by sending message to the port towards DCache
object. If DCache rejects the message (for being blocked or busy) CPU will
flush the pipeline and the access will be re-attempted later on. The access
is completed upon receiving reply message (ReadRep) from DCache.
<b>Write access</b> is initiated by storing the request into store buffer whose
context is emptied and sent to DCache on every tick. DCache may also reject
the request. Write access is completed when write reply (WriteRep) message is
received from DCache.
Load & store buffers (for read and write access) don’t impose any
restriction on the number of active memory accesses. Therefore, the maximum
number of outstanding CPU’s memory access requests is not limited by CPU
Simulation Object but by underlying memory system model.
<b>Split memory access</b> is implemented.
The message that is sent by CPU contains memory type (Normal, Device, Strongly
Ordered and cachebility) of the accessed region. However, this is not being used
by the rest of the model that takes more simplified approach towards memory types.
\section gem5_DCache DATA CACHE OBJECT
Data Cache object implements a standard cache structure:
\image html "gem5_MS_Fig2.PNG" "DCache Simulation Object" width=3cm
<b>Cached memory reads</b> that match particular cache tag (with Valid & Read
flags) will be completed (by sending ReadResp to CPU) after a configurable time.
Otherwise, the request is forwarded to Miss Status and Handling Register
(MSHR) block.
<b>Cached memory writes</b> that match particular cache tag (with Valid, Read
& Write flags) will be completed (by sending WriteResp CPU) after the same
configurable time. Otherwise, the request is forwarded to Miss Status and
Handling Register(MSHR) block.
<b>Uncached memory reads</b> are forwarded to MSHR block.
<b>Uncached memory writes</b> are forwarded to WriteBuffer block.
<b>Evicted (& dirty) cache lines</b> are forwarded to WriteBuffer block.
CPU’s access to Data Cache is blocked if any of the following is true:
- MSHR block is full. (The size of MSHR’s buffer is configurable.)
- Writeback block is full. (The size of the block’s buffer is
configurable.)
- The number of outstanding memory accesses against the same memory cache line
has reached configurable threshold value – see MSHR and Write Buffer for details.
Data Cache in block state will reject any request from slave port (from CPU)
regardless of whether it would result in cache hit or miss. Note that
incoming messages on master port (response messages and snoop requests)
are never rejected.
Cache hit on uncachable memory region (unpredicted behaviour according to
ARM ARM) will invalidate cache line and fetch data from memory.
\subsection gem5_MS_TAndDBlock Tags & Data Block
Cache lines (referred as blocks in source code) are organised into sets with
configurable associativity and size. They have the following status flags:
- <b>Valid.</b> It holds data. Address tag is valid
- <b>Read.</b> No read request will be accepted without this flag being set.
For example, cache line is valid and unreadable when it waits for write flag
to complete write access.
- <b>Write.</b> It may accept writes. Cache line with Write flags
identifies Unique state – no other cache memory holds the copy.
- <b>Dirty.</b> It needs Writeback when evicted.
Read access will hit cache line if address tags match and Valid and Read
flags are set. Write access will hit cache line if address tags match and
Valid, Read and Write flags are set.
\subsection gem5_MS_Queues MSHR and Write Buffer Queues
Miss Status and Handling Register (MSHR) queue holds the list of CPU’s
outstanding memory requests that require read access to lower memory
level. They are:
- Cached Read misses.
- Cached Write misses.
- Uncached reads.
WriteBuffer queue holds the following memory requests:
- Uncached writes.
- Writeback from evicted (& dirty) cache lines.
\image html "gem5_MS_Fig3.PNG" "MSHR and Write Buffer Blocks" width=6cm
Each memory request is assigned to corresponding MSHR object (READ or WRITE
on diagram above) that represents particular block (cache line) of memory
that has to be read or written in order to complete the command(s). As shown
on gigure above, cached read/writes against the same cache line have a common
MSHR object and will be completed with a single memory access.
The size of the block (and therefore the size of read/write access to lower
memory) is:
- The size of cache line for cached access & writeback;
- As specified in CPU instruction for uncached access.
In general, Data Cache model distinguishes between just two memory types:
- Normal Cached memory. It is always treated as write back, read and write
allocate.
- Normal uncached, Device and Strongly Ordered types are treated equally
(as uncached memory)
\subsection gem5_MS_Ordering Memory Access Ordering
An unique order number is assigned to each CPU read/write request(as they appear on
slave port). Order numbers of MSHR objects are copied from the first
assigned read/write.
Memory read/writes from each of these two queues are executed in order (according
to the assigned order number). When both queues are not empty the model will
execute memory read from MSHR block unless WriteBuffer is full. It will,
however, always preserve the order of read/writes on the same
(or overlapping) memory cache line (block).
In summary:
- Order of accesses to cached memory is not preserved unless they target
the same cache line. For example, the accesses #1, #5 & #10 will
complete simultaneously in the same tick (still in order). The access
#5 will complete before #3.
- Order of all uncached memory writes is preserved. Write#6 always
completes before Write#13.
- Order to all uncached memory reads is preserved. Read#2 always completes
before Read#8.
- The order of a read and a write uncached access is not necessarily
preserved - unless their access regions overlap. Therefore, Write#6
always completes before Read#8 (they target the same memory block).
However, Write#13 may complete before Read#8.
\section gem5_MS_Bus COHERENT BUS OBJECT
\image html "gem5_MS_Fig4.PNG" "Coherent Bus Object" width=3cm
Coherent Bus object provides basic support for snoop protocol:
<b>All requests on the slave port</b> are forwarded to the appropriate master port. Requests
for cached memory regions are also forwarded to other slave ports (as snoop
requests).
<b>Master port replies</b> are forwarded to the appropriate slave port.
<b>Master port snoop requests</b> are forwarded to all slave ports.
<b>Slave port snoop replies</b> are forwarded to the port that was the source of the
request. (Note that the source of snoop request can be either slave or
master port.)
The bus declares itself blocked for a configurable period of time after
any of the following events:
- A packet is sent (or failed to be sent) to a slave port.
- A reply message is sent to a master port.
- Snoop response from one slave port is sent to another slave port.
The bus in blocked state rejects the following incoming messages:
- Slave port requests.
- Master port replies.
- Master port snoop requests.
\section gem5_MS_SimpleMemory SIMPLE MEMORY OBJECT
It never blocks the access on slave port.
Memory read/write takes immediate effect. (Read or write is performed when
the request is received).
Reply message is sent after a configurable period of time .
\section gem5_MS_MessageFlow MESSAGE FLOW
\subsection gem5_MS_Ordering Read Access
The following diagram shows read access that hits Data Cache line with Valid
and Read flags:
\image html "gem5_MS_Fig5.PNG" "Read Hit (Read flag must be set in cache line)" width=3cm
Cache miss read access will generate the following sequence of messages:
\image html "gem5_MS_Fig6.PNG" "Read Miss with snoop reply" width=3cm
Note that bus object never gets response from both DCache2 and Memory object.
It sends the very same ReadReq package (message) object to memory and data
cache. When Data Cache wants to reply on snoop request it marks the message
with MEM_INHIBIT flag that tells Memory object not to process the message.
\subsection gem5_MS_Ordering Write Access
The following diagram shows write access that hits DCache1 cache line with
Valid & Write flags:
\image html "gem5_MS_Fig7.PNG" "Write Hit (with Write flag set in cache line)" width=3cm
Next figure shows write access that hits DCache1 cache line with Valid but no
Write flags – which qualifies as write miss. DCache1 issues UpgradeReq to
obtain write permission. DCache2::snoopTiming will invalidate cache line that
has been hit. Note that UpgradeResp message doesn’t carry data.
\image html "gem5_MS_Fig8.PNG" "Write Miss – matching tag with no Write flag" width=3cm
The next diagram shows write miss in DCache. ReadExReq invalidates cache line
in DCache2. ReadExResp carries the content of memory cache line.
\image html "gem5_MS_Fig9.PNG" "Miss - no matching tag" width=3cm
*/

129
src/doc/power_thermal_model.doxygen
View File

@@ -1,129 +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.
*/