This commit adds the concept of possible power states to the
PowerState SimObject. This is a list of the power states a specific
object can be in. Before transitioning to a power state, a PowerState
object will first check if the requested power states is actually an
allowed state. The user can restricted the power states a
ClockedObject can go to during configuration. In addition, this change
sets the power states, a CPU can be in.
Change-Id: Ida414a87554a14f09767a272b54b5d19bfc8e911
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28050
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit does not make any functional changes but just rearranges
the existing code with regard to the power states. Previously, all
code regarding power states was in the ClockedObjects. However, it
seems more logical and cleaner to move this code into a separate
class, called PowerState. The PowerState is a now SimObject. Every
ClockedObject has a PowerState but this patch also allows for objects
with PowerState which are not ClockedObjects.
Change-Id: Id2db86dc14f140dc9d0912a8a7de237b9df9120d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28049
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
fs_power.py is an example script that demonstrates how power models
can be used with gem5. Previously, the formulas used to calculate the
dynamic and static power of the cores and the L2 cache were using
stats in equations as determined by their path relative to the
SimObject where the power model is attached to or full paths. This CL
changes these formulas to refer to the stats only by their full paths.
Change-Id: I91ea16c88c6a884fce90fd4cd2dfabcba4a1326c
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27893
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
With the introduction of StatGroups the organization of stats has
changed and the power modeling framework has been broken. This CL uses
the new function Stats::resolve to retrieve pointers to the necesary
stats and use them in the power estimation formulas.
Change-Id: Iedaa97eeddf51f7a0a1f222918715da309943be3
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27892
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This change adds a member function to the Group class that returns a
stat given its name. The function will go through all stats in the
group and its subgroups and will return the stat that matches the
name. For example, if g is the Group system.bigCluster.cpus then a
call to
p = g.resolveStat("ipc")
will return a pointer to the stat system.bigCluster.cpus.ipc.
Change-Id: I5af8401b38b41aee611728f6d1a595f99d22d9de
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27890
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
New tests were added for:
- garnet_synth_traffic.py
- ruby_random_test.py
- ruby_direct_test.py
These tests are factored out with the tests for:
- memcheck.py
- ruby_mem_test.py
Each new test was calibrated to last about 5 seconds on a Lenovo ThinkPad
P51.
Change-Id: Ie13d3963e1163cffae5dce329b623fbebbf2b983
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26808
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The file was raising due to the undefined constant `verifiers`, leading
the test to be ignored.
./main.py list -v
would show this as:
```
Traceback (most recent call last):
File "/gem5/tests/../ext/testlib/loader.py", line 239, in load_file
execfile(path, newdict, newdict)
File "/gem5/tests/gem5/memcheck/test_memcheck.py", line 32, in <module>
verifiers=verifiers,
NameError: name 'verifiers' is not defined
Exception thrown while loading "/gem5/tests/gem5/memcheck/test_memcheck.py"
Ignoring all tests in this file.
```
The test has been modified to have an empty verifiers list, which should
still catch bugs since src/mem/mem_checker.cc has several asserts already
which would be caught by the test system due to the exit status.
Also make the following changes to the test:
- move it to tests/gem5/memory/test.py with other memory tests.
This makes it easier to see all the tests in the source in one go, and
might make it easier to factor certain memory things out later on.
- reduce --maxtick to a value that finishes in 7 seconds on a Lenovo
ThinkPad P51.
The previous value would take 50x longer, which feels too long for a
single test.
- enable --prefetchers to also stress a prefetcher in the test
Change-Id: I58bd598b1142f349d25fa4fa4a8e41529e61a9ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26807
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this change, running:
./build/NULL/gem5.opt configs/example/ruby_mem_test.py -m 20000000 \
--functional 10
would only print warning for memory errors such as:
warn: Read access failed at 0x107a00
and there was no way to make the simulation fail.
This commit makes those warnings into errors such as:
panic: Read access failed at 0x107a00
unless --suppress-func-errors is given.
This will be used to automate MemTest testing in later commits.
Change-Id: I1840c1ed1853f1a71ec73bd50cadaac095794f91
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26804
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
According to the debugging spec (page 47), a debugger can test which
triggers are enabled by writing 0 to TSELECT and reading it back. If a
different value is read, the trigger is not supported.
Therefore, we currently always set a different value to indicate that
we do not support any triggers.
Change-Id: If222e913c4517adb2da4f6f0ffeedb4e4808a586
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25659
Tested-by: kokoro <noreply+kokoro@google.com>
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>
According to the privileged ISA spec, SEPC[0]/MEPC[0] reads always 0
and SEPC[1]/MEPC[1] reads 0 if the compressed extension is disabled.
Additionally, the compressed extension can only be disabled if the next
instruction is 4-byte aligned.
Change-Id: I590c05e4000b59a5ba283f47933f7a92959d8e38
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25658
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
According to page 57 in the RISC-V manual, CSR accesses "need to be
performed in program order with respect to those instructions whose
execution behavior is affected by the state of the accessed CSR".
Thus, we need to make them SerializeAfter to ensure that the following
instructions are executed with the potential changes to the CSR. In
theory, we could be smarter here by only considering write accesses to
CSRs and considering the following instructions, but for now we simply
serialize for every CSR access.
Change-Id: I69391fccaec31c34d944c55bac2f04d37947ebfe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25655
Tested-by: kokoro <noreply+kokoro@google.com>
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>
That is, RISC-V has now a TLB and page table walker for Sv39 paging
according to the privileged ISA 1.11.
Both the TLB and PT walker are based on x86 (the code duplication of the
page table walkers will be reduced by a separate commit).
Change-Id: I5e29683bdd40c0d32c06e4d75a8382bf313f2086
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25647
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This test covers the templates which attempt to classify types, but not the
actual gathering of arguments of distribution of return values. As before, we
can't really use standard C++ to accurately test for HFAs and HVAs, so we stick
with approximating them by detecting arrays of the right types.
For example, I think technically we should also accept a struct with only 4
float members, but c++ templates aren't able to match against types in that way
as far as I know.
Change-Id: I1d7756a964a86c0c5ea13e068a5fc74603e14e30
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28268
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The templates which checked for short vectors, and our approximation of
HFA, HVA and HXA types were not correct. This change actually simplifies
them along with getting them to produce correct results. In the case of
HXA, there was a logic bug where an && was used where an || was
intended.
There may still be bugs in the actual collection of arguments and
setting of return values since those aspects are harder to test.
Change-Id: Ice3177205a98c678ecb43ba600813b3909c44e6b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28267
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These make the calling code in m5.c a little bit more generic. Each call
type will have a function to check the arguments and see if that type is
being requested and/or has any additional options set in the arguments.
If so, those are processed, and argc and argv are adjusted.
Then another function returns the appropriate dispatch table to use for
that invocation scheme. This is behind a function instead of, for
instance, a global variable because it gives the call type a little bit
more control over what's happening, for instance if it would use
different implementations in slightly different circumstances.
Change-Id: I661cf202ec657466496767cbdf331fe27995ab26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27241
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
I've needed this type of macro often when writing code which uses the
M5OP_FOREACH macro, and so rather than re-write it each time, lets just
put a version here. This is such a common type of macro to need that
you'd think it would be part of a standard header somewhere, but to my
knowledge it isn't.
Change-Id: I0df0d9d2fd7ce1b9e6c355d6e4db197ccfff7c35
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27239
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
It may be the case that each item M5OP_FOREACH iterates over should end
in a ',' and not a ';', for instance when putting each item into an
array or initializing a structure. If the caller still wants a ';', they
can add it into the definition of the M5OP macro.
Change-Id: Idd6538b0aad27df39658c3f749c6ff5e4fe55e6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27237
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These shouldn't be called in fs mode through the m5 utility and
probably shouldn't be called directly either, but this makes them
consistent with the other functions which are mentioned in
asm/generic/m5ops.h.
Change-Id: I80df8b4d507350bc6d2763e770e38e0370931632
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27236
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Make sure all the operations that have constants (and aren't deprecated
or reserved) and present in M5OP_FOREACH in order of their constants.
Also move M5OP_ANNOTATE up so that all the constants are also in order.
Change-Id: I8d9f69b020aeb39311a24606a286a76de10a51cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27234
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a small additional layer on top of the initparam command and
just breaks the returned value into 12 bit chunks. It presumes that
there is some particular meaning to the default initparam value which
may or may not be true. It's not entirely clear what the 12 bit chunks
that this command returns are actually good for, and it's been around
long enough that there isn't really any good documentation about what
it's intended purpose was.
Change-Id: I21af0e0cf7501f47026a6dd31920d46cfccff167
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27232
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Take advantage of string comparisons when looking up what to do with a
given key.
Convert the key_str[12] registers from little endian to host endian.
This matches a corresponding change in the m5 utility to pack the
registers in little endian order, regardless of what the actual guest
endianness is.
Absorb the initparam_keys.hh header into sim/pseudo_inst.cc, and convert
its constants to c++ strings. The constants defined in it might be
useful to guest code calling into the m5 ops, but not for gem5 itself.
By merging them into the .cc file, we also don't have to do any tricks to
try to avoid them having multiple definitions.
Change-Id: I3a450ad7f9c4dca25f79c7835d7f9c167c02ae98
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27230
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This change removes the responsibility for checking the number of
arguments and handing the default of no string back into init_param and
out of the function which packs strings into registers. It also renames
the function to more closely match its purpose, and rewrites it to be a
bit simpler and (IMHO) easier to follow.
Importantly, rather than doing a hand implemented strcpy which would
follow the endianness of the target/simulated platform, this change
makes this function pack the registers explicitly in little endian byte
order. This way on the consuming end in gem5, the initParam function
doesn't have to care what the guest endianness is, it can just translate
them from little endian to whatever the host endianness is (very likely
also little endian).
Change-Id: Ie9f79ecb8d4584c6e47a2793a31ccaa8c7c15986
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27229
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If the first register is all zeroes, it doesn't really matter what the
other register is. If the first register has the entire string, we still
don't care what the other register has in it. There's no reason to
complicate the code with these extra checks.
Change-Id: I22ad521b9ace915ccb75f15934fc6b3d650d5293
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27228
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
