This patch hosts gem5 onto SystemC scheduler. There's already an upstream
review board patch that does something similar but this patch ...:
1) is less obtrusive to the existing gem5 code organisation. It's divided
into the 'generic' preparatory patches (already submitted) and this patch
which affects no existing files
2) does not try to exactly track the gem5 event queue with notifys into
SystemC and so doesn't requive the event queue to be modified for
anything other than 'out of event queue' scheduling events
3) supports debug logging with SC_REPORT
The patch consists of the files:
util/systemc/
sc_gem5_control.{cc,hh} -- top level objects to use to
instantiate gem5 Systems within
larger SystemC test harnesses as
sc_module objects
sc_logger.{cc,hh} -- logging support
sc_module.{cc,hh} -- a separated event loop specific to
SystemC
stats.{cc,hh} -- example Stats handling for the sample
top level
main.{cc,hh} -- a sample top level
On the downside this patch is only currently functional with C++
configuration at the top level.
The above sc_... files are indended to be compiled alongside gem5 (as a
library, see main.cc for a command line and util/systemc/README for
more details.)
The top-level system instantiation in sc_gem5_control.{cc,hh} provides
two classes: Gem5Control and Gem5System
Gem5Control is a simulation control class (from which a singleton
object should be created) derived from Gem5SystemC::Module which
carries the top level simulation control interface for gem5. This
includes hosting a system-building configuration file and
instantiating the Root object from that file.
Gem5System is a base class for instantiating renamed gem5 Systems
from the config file hosted by the Gem5Control object. In use, a
SystemC module class should be made which represents the desired,
instantiable gem5 System. That class's instances should create
a Gem5System during their construction, set the parameters of that
system and then call instantiate to build that system. If this
is all carried out in the sc_core::sc_module-derived classes
constructor, the System's external ports will become children of
that module and can then be recovered by name using sc_core::
sc_find_object.
It is intended that this interface is used with dlopen. To that
end, the header file sc_gem5_control.hh includes no other header
files from gem5 (and so can be easily copied into another project).
The classes Gem5System and Gem5Control have all their member
functions declared `virtual' so that those functions can be called
through the vtable acquired by building the top level Gem5Control
using dlsym(..., "makeGem5Control") and `makeSystem' on the
Gem5Control.
This patch adds a 'wakeup' member function to EventQueue which should be
called on an event queue whenever an event is scheduled on the event queue
from outside code within the call tree of the gem5 event loop.
This clearly isn't necessary for normal gem5 EventQueue operation but
becomes the minimum necessary interface to allow hosting gem5's event loop
onto other schedulers where there may be calls into gem5 from external
code which schedules events onto an EventQueue between the current time and
the time of the next scheduled event.
The use case I have in mind is a SystemC hosting where the event loop is:
while (more events) {
wait(time_to_next_event or wakeup)
setCurTick
service events at this time
}
where the 'wait' needs to be woken up if time_to_next_event becomes shorter
due to a scheduled event from SystemC arriving in a gem5 object.
Requiring 'wakeup' to be called is a more efficient interface than
requiring all gem5 event scheduling actions to affect the host scheduler.
This interface could be located elsewhere, say on another global object,
or by being passed by the host scheduler to objects which will schedule
such events, but it seems cleanest to put it on EventQueue as it is
actually a signal to the queue.
EventQueue::wakeup is called for async_event events on event queue 0 as
it's only important that *some* queue be triggered for such events.
This patch adds a Logger class encapsulating dprintf. This allows
variants of DPRINTF logging to be constructed and substituted in
place of the default behaviour.
The Logger provides a logMessage(when, name, format, ...) member
function like Trace::dprintf and a getOstream member function to
use a raw ostream for logging.
A class OstreamLogger is provided which generates the customary
debugging output with Trace::OstreamLogger::logMessage being the
old Trace::dprintf.
This patch takes quite a large step in transitioning from the ad-hoc
RefCountingPtr to the c++11 shared_ptr by adopting its use for all
Faults. There are no changes in behaviour, and the code modifications
are mostly just replacing "new" with "make_shared".
This patch transitions the o3 MemDepEntry from the ad-hoc
RefCountingPtr to the c++11 shared_ptr. There are no changes in
behaviour, and the code modifications are mainly replacing "new" with
"make_shared".
This patch transitions the Ruby Message and its derived classes from
the ad-hoc RefCountingPtr to the c++11 shared_ptr. There are no
changes in behaviour, and the code modifications are mainly replacing
"new" with "make_shared".
The cloning of derived messages is slightly changed as they previously
relied on overriding the base-class through covariant return types.
This patch transitions the stat Node and its derived classes from
the ad-hoc RefCountingPtr to the c++11 shared_ptr. There are no
changes in behaviour, and the code modifications are mainly replacing
"new" with "make_shared".
This patch transitions the EthPacketData from the ad-hoc
RefCountingPtr to the c++11 shared_ptr. There are no changes in
behaviour, and the code modifications are mainly replacing "new" with
"make_shared".
The bool casting operator for the shared_ptr is explicit, and we must
therefore either cast it, compare it to NULL (p != nullptr), double
negate it (!!p) or do a (p ? true : false).
This patch takes a first few steps in transitioning from the ad-hoc
RefCountingPtr to the c++11 shared_ptr. There are no changes in
behaviour, and the code modifications are mainly introducing the
use of make_shared.
Note that the class could use unique_ptr rather than shared_ptr, was
it not for the postfix increment and decrement operators.
This patch makes the memory system ISA-agnostic by enabling the Ruby
Sequencer to dynamically determine if it has to do a store check. To
enable this check, the ISA is encoded as an enum, and the system
is able to provide the ISA to the Sequencer at run time.
--HG--
rename : src/arch/x86/insts/microldstop.hh => src/arch/x86/ldstflags.hh
This patch takes a step towards an ISA-agnostic memory
system by enabling the components to establish the page size after
instantiation. The swap operation in the memory is now also allowing
any granularity to avoid depending on the IntReg of the ISA.
This changeset adds probe points that can be used to implement PMU
counters for CPU stats. The following probes are supported:
* BaseCPU::ppCycles / Cycles
* BaseCPU::ppRetiredInsts / RetiredInsts
* BaseCPU::ppRetiredLoads / RetiredLoads
* BaseCPU::ppRetiredStores / RetiredStores
* BaseCPU::ppRetiredBranches RetiredBranches
This changeset adds probe points that can be used to implement PMU
counters for TLB stats. The following probes are supported:
* ArmISA::TLB::ppRefills / TLB Refills (TLB insertions)
This changeset adds probe points that can be used to implement PMU
counters for branch predictor stats. The following probes are
supported:
* BPRedUnit::ppBranches / Branches
* BPRedUnit::ppMisses / Misses
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.
In order to show make PMU probe points usable across different PMU
implementations, we want a common probe interface. This patch the
namespace ProbePoins that contains typedefs for probe points that are
shared between multiple SimObjects. It also adds typedefs for the PMU
probe interface.
BitUnion instances can normally not be used with the SERIALIZE_SCALAR
and UNSERIALIZE_SCALAR macros due to the way they are converted
between their storage type and their actual type. This changeset adds
a set of parm(In|Out) functions specifically for gem5 bit unions to
work around the issue.
This patch adds the ability to load in config.ini files generated from
gem5 into another instance of gem5 built without Python configuration
support. The intended use case is for configuring gem5 when it is a
library embedded in another simulation system.
A parallel config file reader is also provided purely in Python to
demonstrate the approach taken and to provided similar functionality
for as-yet-unknown use models. The Python configuration file reader
can read both .ini and .json files.
C++ configuration file reading:
A command line option has been added for scons to enable C++ configuration
file reading: --with-cxx-config
There is an example in util/cxx_config that shows C++ configuration in action.
util/cxx_config/README explains how to build the example.
Configuration is achieved by the object CxxConfigManager. It handles
reading object descriptions from a CxxConfigFileBase object which
wraps a config file reader. The wrapper class CxxIniFile is provided
which wraps an IniFile for reading .ini files. Reading .json files
from C++ would be possible with a similar wrapper and a JSON parser.
After reading object descriptions, CxxConfigManager creates
SimObjectParam-derived objects from the classes in the (generated with this
patch) directory build/ARCH/cxx_config
CxxConfigManager can then build SimObjects from those SimObjectParams (in an
order dictated by the SimObject-value parameters on other objects) and bind
ports of the produced SimObjects.
A minimal set of instantiate-replacing member functions are provided by
CxxConfigManager and few of the member functions of SimObject (such as drain)
are extended onto CxxConfigManager.
Python configuration file reading (configs/example/read_config.py):
A Python version of the reader is also supplied with a similar interface to
CxxConfigFileBase (In Python: ConfigFile) to config file readers.
The Python config file reading will handle both .ini and .json files.
The object construction strategy is slightly different in Python from the C++
reader as you need to avoid objects prematurely becoming the children of other
objects when setting parameters.
Port binding also needs to be strictly in the same port-index order as the
original instantiation.
This patch adds the Undefined Behavior Sanitizer (UBSan) for clang and
gcc >= 4.9. Due to the performance impact, the usage is guarded by a
command-line option.
Add the ability to build libgem5 without embedded Python or the
ability to configure with Python.
This is a prelude to a patch to allow config.ini files to be loaded
into libgem5 using only C++ which would make embedding gem5 within
other simulation systems easier.
This adds a few registration interfaces to things which cross
between Python and C++. Namely: stats dumping and SimObject resolving
This patch adds a python script that processes the configuration and the
statistics file from a simulation run. Configuration and activity of network
routers and links obtained from this processing is fed to DSENT via its Python
interface. DSENT then computes the area and the power consumption of these
network components. The script outputs these quantities to the console.
This patch extensively modifies DSENT so that it can be accessed using Python.
To access the Python interface, DSENT needs to compiled as a shared library.
For this purpose a CMakeLists.txt file has been added. Some of the code that
is not required is being removed.
This patch adds a tool called DSENT to the ext/ directory. DSENT
is a tool that models power and area for on-chip networks. The next
patch adds a script for using the tool.
This patch adds some statistics to garnet that record the activity
of certain structures in the on-chip network. These statistics, in a later
patch, will be used for computing the energy consumed by the on-chip network.
Orion is being dropped from ruby. It would be replaced with DSENT
which has better models. Note that the power / energy numbers reported
after this patch has been applied are not for use.
This patch moves code for instantiating a single memory controller from
the function config_mem() to a separate function. This is being done
so that memory controllers can be instantiated without assuming that
they will be attached to the system in a particular fashion.
This patch force IO device to be mapped to 0xC0000000-0xFFFF0000 by
reserve anything between the end of memory and 3GB if memory is less
than 3GB. It also statically bridge these address range to the IO bus,
which guaranty access to pci address space will pass though bridge to
iobus.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
This patch assign bus_id=0 to PCI bus and bus_id=1 to ISA bus for
X86 platform. Because PCI device get config space address using
Pc::calcPciConfigAddr() which requires "assert(bus==0)".
This fixes PCI interrupt routing and discovery on Linux.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
This patch takes the final step in integrating DRAMPower and adds the
appropriate calls in the DRAM controller to provide the command trace
and extract the power and energy stats. The debug printouts are still
left in place, but will eventually be removed.
At the moment the DRAM power calculation is always on when using the
DRAM controller model. The run-time impact of this addition is around
1.5% when looking at the total host seconds of the regressions. We
deem this a sensible trade-off to avoid the complication of adding an
enable/disable mechanism.
This patch adds a class to wrap DRAMPower Library in gem5.
This class initiates an object of class MemorySpecification
of the DRAMPower Library, passes the parameters from DRAMCtrl.py
to this object and creates an object of drampower library using
the memory specification.
This patch adds missing timing and current parameters to the existing
DRAM configs. These missing timing and current parameters are required
by DRAMPower for the DRAM power calculations. The missing values are
datasheet values of the specified DRAMs, and the appropriate
references are added for the variuos configs.
This patch prunes the DDR3 config that was initially created to match
the default config of DRAMSim2. The config is not complete as it is,
and to avoid having to maintain it, the easiest way forward is to
simply prune it. Going forward we are adding power number etc to the
other configurations.
This patch adds the open-source (BSD 3-clause) tool DRAMPower, commit
8d3cf4bbb10aa202d850ef5e5e3e4f53aa668fa6, to be built as a part of the
simulator. We have chosen this specific version of DRAMPower as it
provides the necessary functionality, and future updates will be
coordinated with the DRAMPower development team. The files added only
include the bits needed to build the library, thus excluding all
memory specifications, traces, and the stand-alone DRAMPower
command-line tool.
A future patch includes the DRAMPower functionality in the DRAM
controller, to enable on-line DRAM power modelling, and avoid using
post-processing of traces.
