This patch adds a config script that broadly replicates the behaviour
of lat_mem_rd. The test is based on traffic generators, and as such we
simply randomise addresses in increasingly large ranges, and play them
back using the trace functionality of the traffic generator.
The test script is accompanied by a post-processing and visualisation
script. At the moment no configurability is added to tweak the memory
hierarchy, but a follow on patch could easily extend the
functionality.
Bug fix for check on protobuf file frequency being different than
global frequency.
The ASCII encoder script is also fixed, and the example trace used in
the regressions is updated.
Added a new Verifier object to check for and fix spacing
between if/while/for and following paren.
Restructured Verifier class to make it easier to add
new subclasses, particularly by using a global list of
verifiers to auto-generate command line options and
simplify the invocation loop.
The functions in these scripts were apparently folded into style.py but the
old scripts were orphaned without being deleted. Get rid of them so their
existence is no longer confusing.
Distributed gem5 (abbreviated dist-gem5) is the result of the
convergence effort between multi-gem5 and pd-gem5 (from Univ. of
Wisconsin). It relies on the base multi-gem5 infrastructure for packet
forwarding, synchronisation and checkpointing but combines those with
the elaborated network switch model from pd-gem5.
--HG--
rename : src/dev/net/multi_etherlink.cc => src/dev/net/dist_etherlink.cc
rename : src/dev/net/multi_etherlink.hh => src/dev/net/dist_etherlink.hh
rename : src/dev/net/multi_iface.cc => src/dev/net/dist_iface.cc
rename : src/dev/net/multi_iface.hh => src/dev/net/dist_iface.hh
rename : src/dev/net/multi_packet.hh => src/dev/net/dist_packet.hh
Previous ARM-based simulations were limited to 8 cores due to
limitations in GICv2 and earlier. This changeset adds a set of
gem5-specific extensions that enable support for up to 256 cores.
When the gem5 extensions are enabled, the GIC uses CPU IDs instead of
a CPU bitmask in the GIC's register interface. To OS can enable the
extensions by setting bit 0x200 in ICDICTR.
This changeset is based on previous work by Matt Evans.
This patch adds support to optionally capture the virtual address and asid
for load/store instructions in the elastic traces. If they are present in
the traces, Trace CPU will set those fields of the request during replay.
This patch replaces the booleans that specified the elastic trace record
type with an enum type. The source of change is the proto message for
elastic trace where the enum is introduced. The struct definitions in the
elastic trace probe listener as well as the Trace CPU replace the boleans
with the proto message enum.
The patch does not impact functionality, but traces are not compatible with
previous version. This is preparation for adding new types of records in
subsequent patches.
With clang there are systems without gcc being installed anymore and we should
not rely on that. This patch drops CC so that system's default compiler is
invoked.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
Due to changes in Drain Manager, the lastest systemc coupling doesn't work. The
code for handling Checkpoint has been modified and it is now compatiable with
new drain manager.
Testing is being done on systemC coupling. It needs more testing to verify
checkpointing feature.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
The DTRACE() macro tests both Trace::enabled and the specific flag. This
change uses the same administrative interface for enabling/disabling
tracing, but masks the SimpleFlags settings directly. This eliminates a
load for every DTRACE() test, e.g. DPRINTF.
If the terminal was used in the SystemC or TLM simulations the simulation gets
in a deadlock state. This is because of the Event queue gets locked while
servicing the async events leading to event queue deadlock. This was solved by
locking the queue at the beginning of service of async events.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
The CleanEvict command was not considered in /util/tlm/sc_port.cc this could
lead to a simulator crash. This issue is solved by ignoring this special
command type.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
Rewrite the HDLCD controller to use the new DMA engine and pixel
pump. This fixes several bugs in the current implementation:
* Broken/missing interrupt support (VSync, underrun, DMA end)
* Fragile resolution changes (changing resolutions used
to cause assertion errors).
* Support for resolutions with a width that isn't divisible by 32.
* The pixel clock can now be set dynamically.
This breaks checkpoint compatibility. Checkpoints can be upgraded with
the checkpoint conversion script. However, upgraded checkpoints won't
contain the state of the current frame. That means that HDLCD
controllers restoring from a converted checkpoint immediately start
drawing a new frame (i.e, expect timing differences).
This commit addresses gem5 checkpoints' linear versioning bottleneck.
Since development is distributed across many private trees, there exists
a sort of 'race' for checkpoint version numbers: internally a checkpoint
version may be used but then resynchronizing with the external tree causes
a conflict on that version. This change replaces the linear version number
with a set of unique strings called tags. Now the only conflicts that can
arise are of tag names, where collisions are much easier to avoid.
The checkpoint upgrader (util/cpt_upgrader.py) upgrades the version
representation, as one would expect. Each tag version implements its
upgrader code in a python file in the util/cpt_upgraders directory
rather than adding a function to the upgrader script itself.
The version tags are stored in the 'Globals' section rather than 'root'
(as the version was previously) because 'Globals' gets unserialized
first and can provide a warning before any other unserialization errors
can occur.
This patch enhances the functionality of the DRAM sweep script to not
only plot the bandwidth utilisation, but also total power and power
efficiency. To do so, a command-line switch is added, and a bit more
data extracted from the stats.
Transaction Level Modeling (TLM2.0) is widely used in industry for creating
virtual platforms (IEEE 1666 SystemC). This patch contains a standard compliant
implementation of an external gem5 port, that enables the usage of gem5 as a
TLM initiator component in SystemC based virtual platforms. Both TLM coding
paradigms loosely timed (b_transport) and aproximately timed (nb_transport) are
supported.
Compared to the original patch a TLM memory manager was added. Furthermore, the
transaction object was removed and for each TLM payload a PacketPointer that
points to the original gem5 packet is added as an TLM extension. For event
handling single events are now created.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
This patch extends the previous patch's alterations around fd_map. It cleans
up some of the uglier code in the process file and replaces it with a more
concise C++11 version. As part of the changes, the FdMap class is pulled out
of the Process class and receives its own file.
Multi gem5 is an extension to gem5 to enable parallel simulation of a
distributed system (e.g. simulation of a pool of machines
connected by Ethernet links). A multi gem5 run consists of seperate gem5
processes running in parallel (potentially on different hosts/slots on
a cluster). Each gem5 process executes the simulation of a component of the
simulated distributed system (e.g. a multi-core board with an Ethernet NIC).
The patch implements the "distributed" Ethernet link device
(dev/src/multi_etherlink.[hh.cc]). This device will send/receive
(simulated) Ethernet packets to/from peer gem5 processes. The interface
to talk to the peer gem5 processes is defined in dev/src/multi_iface.hh and
in tcp_iface.hh.
There is also a central message server process (util/multi/tcp_server.[hh,cc])
which acts like an Ethernet switch and transfers messages among the gem5 peers.
A multi gem5 simulations can be kicked off by the util/multi/gem5-multi.sh
wrapper script.
Checkpoints are supported by multi-gem5. The checkpoint must be
initiated by a single gem5 process. E.g., the gem5 process with rank 0
can take a checkpoint from the bootscript just before it invokes
'mpirun' to launch an MPI test. The message server process will notify
all the other peer gem5 processes and make them take a checkpoint, too
(after completing a global synchronisation to ensure that there are no
inflight messages among gem5).
This patch adds a random option to memtest.py which allows the user to
easily test valid random tree topologies. The patch also adds a
wrapper script to run soak tests using the newly introduced option.
We also adjust the progress interval and progress limit check to make
the output less noisy, and avoid false positives.
Bring on the pain.
The m5format command didn't actually work due to parameter handling
issues and missing language detection. This changeset fixes those
issues and cleans up some of the code to shared between the style
checker and the format checker.
The style used to support the option -w to automatically fix white
space issues. However, this option was actually wired up to fix all
styles issues the checker encountered. This changeset cleans up the
code that handles automatic fixing and adds an option to fix all
issues, and separate options for white spaces and include ordering.
As of August 2014, the gem5 style guide mandates that a source file's
primary header is included first in that source file. This helps to
ensure that the header file does not depend on include file ordering
and avoids surprises down the road when someone tries to reuse code.
In the new order, include files are grouped into the following blocks:
* Primary header file (e.g., foo.hh for foo.cc)
* Python headers
* C system/stdlib includes
* C++ stdlib includes
* Include files in the gem5 source tree
Just like before, include files within a block are required to be
sorted in alphabetical order.
This changeset updates the style checker to enforce the new order.
This patch fixes checkpoint restore in the SystemC hosting example by handling
early PollEvent events correctly before any EventQueue events are posted.
The SystemC event queue handler (SCEventQueue) reports an error if the event
loop is entered with no Events posted. It is possible for this to happen
after instantiate due to PollEvent events. This patch separates out
`external' events into a different handler in sc_module.cc to prevent the
error from occurring.
This fix also improves the event handling of asynchronous events by:
1) Making asynchronous events 'catch up' gem5 time to SystemC
time to avoid the appearance that events have been lost
while servicing an asynchronous event that schedules an
event loop exit event
2) Add an in_simulate data member to Module to allow the event
loop to check whether events should be processed or deferred
until the next time Module::simulate is entered
3) Cancel pending events around the entry/exit of the event loop
in Module::simulate
4) Moving the state initialisation of the example entirely into
run to correct a problem with early events in checkpoint
restore.
It is still possible to schedule asynchronous events (and talk PollQueue
actions) while simulate is not running. This behaviour may stil cause
some problems.
This patch cleans up a few style issues and adds a few capabilities to the
SystemC top level 'Gem5Control/Gem5System' mechanism. These include:
1) A space to store/retrieve a version string for a model
2) A mechanism for registering functions to be called at the end of
elaboration to perform simulation setup tasks in SystemC
3) Adding setGDBRemotePort to the Gem5Control
4) Changing the sc_set_time_resolution behaviour to instead check that
the SystemC time resolution is already acceptable
This patch adds methods in KvmCPU model to handle KVM exits caused by syscall
instructions and page faults. These types of exits will be encountered if
KvmCPU is run in SE mode.
This patch fixes the checkpoint restore option in the example of C++
configuration (util/cxx_config).
The fix introduces a call to config_manager->startup() (which calls startup
on all SimObjects managed by that manager) to replicate the loop of
SimObject::startup calls in src/python/m5/simulate.py::simulate guarded by
need_startup. As util/cxx_config/main.cc is a C++ analogue of
src/python/mt/simulate.py, it should make a similar set of calls.
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 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 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.
