This is a major change in our platform configuration.
At the moment the VExpress_GEM5_V1 and VExpress_GEM5_V2 platforms
both instantiate an HDLcd device. As the presence of the device
can slow down host performances when the software stack is
aware of its presence, we have historically been providing
an entry in the hdlcd DTB node to "hide" the entry from the
DTB parser:
status = "disable";
This default entry in the hdlcd node will in fact prevent the driver
from bringing up the device. Unfortunately this is useful for
experienced users only which are aware of this knob.
In order to make things more transparent, and to avoid any confusion
(e.g. having the hdlcd present in the config.ini, but not being able to
program it in Linux) we are deprecating this solution; we are removing
the HDLcd from the aforementioned platforms.
Users not interested on simulating a display controller won't
notice the difference.
Users interested on including it, will now have to switch to a new
VExpress_GEM5_Vx_HLCD platform
which will enabled the HDLcd without any further tweaking required
JIRA: https://gem5.atlassian.net/browse/GEM5-866
Change-Id: I4b1920efe764080115a57f52d8a3df2e6e2386a0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38796
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This ABI is effectively used by both the gem5 ops and system calls, in
system calls because it only relies on registers, and in gem5 ops by
inheritance.
Even though these ABIs happen to be the same and were initially defined
to be the same, this change creates a root "reg" ABI which will act as a
root for both so that there isn't an implication that changes to one
should be changes to both.
Change-Id: I8726d8628503be2ad7616a71cc48b66f13e7d955
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39318
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Replacement policy is one of the key points in CPU performance. For ease
of checking the avliable replacment types for any cpu architects,
"replacment policy list" is added in Options.py and ObjectList.py.
Just like Branch Prediction Policies, adding such list would make it efficient for compare cpu performance
regarding different replacment policies especially for Cache.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-853
Change-Id: I97358617038fdcec79fa7e59baba8926284727b4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39195
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
armv7, armv8, armv8_big_little DTS files are reusing the same
encoder node; moreover those should really be cpu specific files.
For these reasons, and to make it possible to craft a final DTS
without defining a display phandle, we move the shared code into
a display DTS include file
Change-Id: I4f756807292e492a743bb9ab9ec511011125a436
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38795
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I797163c8690ae0092e00e371d75f5e7cebbcd1f5
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39579
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I3d0bbfa00968486af8d57c36be2c8bee034bae93
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39577
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I9b47194d26d71c8ebedda6c31a5bac54b600d3bf
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39575
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are the historical "unit test"s, which aren't really unit tests,
they're actually complete builds of gem5 with main functions which run a
fairly specific test instead of a simulation. They test a single unit,
but they do it with all the other units in place and potentially
participating in the test.
Change-Id: Ib0ea68f26091a79992396d932627e4ce180f7825
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39565
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Those instructions were broken after:
https://gem5-review.googlesource.com/c/public/gem5/+/38381/4
Which is effectively replacing the generic StaticInst src and dest
reg array with an instruction specific one.
The size of the array is evaluated by the ISA parser, which is
counting the operands when parsing the isa code.
Alas, Compare and Swap Pair instructions were augmenting the number
of destination and source registers in the C++ world, which is
invisible to the parser. This lead to an out of bounds access
of the arrays.
This patch is fixing this behaviour by defining XResult2, which
is the second compare/result register for a paired CAS
Change-Id: Ie35c26256f42459805e007847896ac58b178fd42
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39456
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As the std namespace expands, it becomes more and more likely that
blanketly importing all its symbols will cause a collision. Also, when
it was imported, the std:: was used or left off arbitrarily, sometimes
inconsistently even in the same function signature.
Change-Id: Ie30cbab154b00c60433908a206c229230d2b109f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39536
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I2d24682d207830f3b7b0ad2ff82b55e082cccb32
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39576
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When running multithreaded programs in SE-mode with DerivO3CPU model,
there are cases that two or more cores have page faults on the same page
in nearby ticks (can be at the same tick) when fetching instructions
(more likely) or accessing data. When these cores try come to the commit
stage in nearby ticks/cycles, they will try to handle the faults
(without clobbering). Then the first core will ask for a physical page
frame to map with the virtual page. In the previous version, the right
next core that tries to handle the fault will hit a panic condition in
the EmulationPageTable::map(...) as the page has been mapped and this
page fault is not to clobber the existing mapping.
In this changeset, if it is found that the page has been mapped and it
is not to clobber the existing mapping, it will return without further
mapping activities as the page fault has been handled previously.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-798
Change-Id: I9bb1163f9d1379c6fed9725101e4400fefdc8079
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39515
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I6ab03934af850494d95a37dcda5c2000794b4d3a
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39578
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The warning happens when a key is present in the checkpoint but not in the
values that gem5 source code knows about.
To do this, we must expose iteration over IniFile section keys. To not
have to make those classes public, a visitor method is implemented.
Change-Id: I23340a953f3e604642b97690a7328b10fdd740a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37575
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit makes it so LGKM count is decremented in a single place
(after completeAcc), which fixes a couple of potential bugs
1. Data is only written by completeAcc, not after initiateAcc. LGKM
count is supposed to be decremented after data is written.
2. LGKM count is now properly decremented for atomics without return
Change-Id: Ic791af3b42e04f7baaa0ce50cb2a2c6286c54f5a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39396
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The second argument in the std::max call is treated as an unsigned value
as all variables are unsigned as well. This will result in an
unsigned underflow, and as such the std::max is a no-op and will result
in the underflowed value.
The `start` and `used` value get corrupted after that, and checks for
`empty` and other stuff downstream break.
Change-Id: I00017e22ba84e65f6b1c596f47d348f342fbc304
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39496
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
