summaryrefslogtreecommitdiff
path: root/src/arch/arm/ArmPMU.py
AgeCommit message (Collapse)Author
2018-09-10arm: Use the interrupt adaptor in the PMUAndreas Sandberg
Rewrite interrupt handling in the PMU model to use the new interrupt adaptor. Change-Id: I2cbb99580c46d3e21a1335b897843b7b6e41f10c Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-on: https://gem5-review.googlesource.com/12400 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
2018-08-02arch-arm: Don't fail to initialise PMU if BP is missingAndreas Sandberg
The branch predictor currently assumes that each CPU has a branch predictor. This isn't true in some cases (e.g., KVM, Atomic). Change-Id: I61e80dca940c2dadba1b812449691c9dba1c06d9 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-on: https://gem5-review.googlesource.com/11520 Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
2017-11-21arch-arm: ArmPMU refactorJose Marinho
Change the definition of PMU events in order to integrate events not cannot easily be represented by probe points. The software increment event is now defined as a special type with its separate implementation in pmu.cc and pmu.hh. Change-Id: I43874b9641bf38c54f6ba2c26386542b6a73e282 Signed-off-by: Jose Marinho <jose.marinho@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5764 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-11-21arch-arm: Do not increment PMU cycle event in WFI/WFEJose Marinho
Change-Id: I09531e9992e045254e5ee989dd11ccabbf84e4ce Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5763 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-07-10arch-arm: Support PMU evens in the 0x4000-0x4040 rangeJose Marinho
ARMv8.1 added a second architected event range, 0x4000-0x4040. Events in this range are discovered using the high word of PMCEID{0,1}_EL0 Change-Id: I4cd01264230e5da4c841268a7cf3e6bd307c7180 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3960
2017-05-02python: Use PyBind11 instead of SWIG for Python wrappersAndreas Sandberg
Use the PyBind11 wrapping infrastructure instead of SWIG to generate wrappers for functionality that needs to be exported to Python. This has several benefits: * PyBind11 can be redistributed with gem5, which means that we have full control of the version used. This avoid a large number of hard-to-debug SWIG issues we have seen in the past. * PyBind11 doesn't rely on a custom C++ parser, instead it relies on wrappers being explicitly declared in C++. The leads to slightly more boiler-plate code in manually created wrappers, but doesn't doesn't increase the overall code size. A big benefit is that this avoids strange compilation errors when SWIG doesn't understand modern language features. * Unlike SWIG, there is no risk that the wrapper code incorporates incorrect type casts (this has happened on numerous occasions in the past) since these will result in compile-time errors. As a part of this change, the mechanism to define exported methods has been redesigned slightly. New methods can be exported either by declaring them in the SimObject declaration and decorating them with the cxxMethod decorator or by adding an instance of PyBindMethod/PyBindProperty to the cxx_exports class variable. The decorator has the added benefit of making it possible to add a docstring and naming the method's parameters. The new wrappers have the following known issues: * Global events can't be memory managed correctly. This was the case in SWIG as well. Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2231 Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Pierre-Yves PĂ©neau <pierre-yves.peneau@lirmm.fr> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2014-10-16arm: Add helper methods to setup architected PMU eventsAndreas Sandberg
2014-10-16arm: Add a model of an ARM PMUv3Andreas Sandberg
This class implements a subset of the ARM PMU v3 specification as described in the ARMv8 reference manual. It supports most of the features of the PMU, however the following features are known to be missing: * Event filtering (e.g., from different privilege levels). * Access controls (the PMU currently ignores the execution level). * The chain counter (event no. 0x1E) is unimplemented. The PMU itself does not implement any events, it merely provides an interface for the configuration scripts to hook up probes that drive events. Configuration scripts should call addEventProbe() to configure custom events or high-level methods to configure architected events. The Python implementation of addEventProbe() automatically delays event type registration until after instantiation. In order to support CPU switching and some combined counters (e.g., memory references synthesized from loads and stores), the PMU allows multiple probes per event type. When creating a system that switches between CPU models that share the same PMU, PMU events for all of the CPU models can be registered with the PMU. Kudos to Matt Horsnell for the initial gem5 implementation of the PMU.