SimObjects
Contents
SimObjects
The python side
Param types
Inheritance
Special attribute names
Rules for importing - how to get what
Pro tips - avoiding cycles, always descend from root, etc.
The C++ side
create functions
Stages of initialization
The basic order of C++ SimObject construction and initialization is controlled by the instantiate()
and simulate()
Python functions in src/python/m5/simulate.py
.
This process was revised in changeset 3f6413fc37a2. This page documents the process as of that changeset.
Once the Python SimObject hierarchy is created by the user's simulation script, that script calls instantiate()
to create the C++ equivalent of that hierarchy. The primary steps in this process are:
- Resolve proxy parameters (those specified using
Self
orParent
). - Dump the
config.ini
file to record the final resolved set of SimObjects and parameter values. - Call the C++ constructors for all of the SimObjects. These constructors are called in an order that satisfies parameter dependencies, i.e., if object A is passed as a parameter to object B, then object A's constructor will be called before object B's constructor so that the C++ pointer to A can be passed to B's constructor. Note that this policy means that cyclic parameter dependencies cannot be supported.
- Instantiate the memory-system port connections. In the case of restoring from a checkpoint, not all ports are connected at this stage, i.e., the switch CPU(s) are not connected.
- Call
init()
on each SimObject. This provides the first opportunity to perform initializations that depend on all SimObjects being fully constructed. - Call
regStats()
on each SimObject. - Call
regFormulas()
on each SimObject. - Complete initialization of SimObject state from a checkpoint or from scratch.
- If restoring from a checkpoint, call
loadState(ckpt)
on each SimObject. The default implementation simply callsunserialize()
if there is a corresponding checkpoint section, so we get backward compatibility with earlier versions of the startup code for existing objects. However, objects can overrideloadState()
to get other behaviors, e.g., doing other programmed initializations afterunserialize()
, or complaining if no checkpoint section is found. - If not restoring from a checkpoint, call
initState()
on each SimObject instead. This provides a hook for state initializations that are only required when not restoring from a checkpoint.
- If restoring from a checkpoint, call
- If restoring from a checkpoint, the switch CPU ports are connected in
BaseCPU::takeOverFrom
at this stage. - Later, the first time that the user script calls
simulate()
, callstartup()
on each SimObject. This is the point where SimObjects that do self-initiated processing should schedule internal events, since the value ofcurTick
could change during unserialization.
Initialization Function Call Sequence
The figure below shows the function call sequence for the initialization of gem5 when running the "Hello, World" example given in the Introduction section. Each node in the graph gives the path to the source code file in which the function is located. This representation should aid in the first steps of familiarization with the basic initialization steps of gem5, including how the configuration files are used and how the objects are constructed.