Difference between revisions of "SimObjects"
From gem5
(→Stages of initialization) |
Nilayvaish (talk | contribs) (→Stages of initialization: Corrected the link, removed the step on regFormulas()) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 15: | Line 15: | ||
====Stages of initialization==== | ====Stages of initialization==== | ||
| − | The basic order of C++ SimObject construction and initialization is controlled by the <code>instantiate()</code> and <code>simulate()</code> Python functions in <code>src/python/m5/simulate.py</code>. | + | The basic order of C++ SimObject construction and initialization is controlled by the <code>instantiate()</code> and <code>simulate()</code> Python functions in <code>src/python/m5/simulate.py</code>. This process was revised in [http://repo.m5sim.org/gem5?cmd=changeset;node=3f6413fc37a2 changeset 3f6413fc37a2]. This page documents the process as of that changeset. |
| − | |||
| − | This process was revised in [http://repo.m5sim.org/ | ||
Once the Python SimObject hierarchy is created by the user's simulation script, that script calls <code>instantiate()</code> to create the C++ equivalent of that hierarchy. The primary steps in this process are: | Once the Python SimObject hierarchy is created by the user's simulation script, that script calls <code>instantiate()</code> to create the C++ equivalent of that hierarchy. The primary steps in this process are: | ||
| Line 24: | Line 22: | ||
# Dump the <code>config.ini</code> file to record the final resolved set of SimObjects and parameter values. | # Dump the <code>config.ini</code> 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. | # 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. | + | # 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 <code>init()</code> on each SimObject. | + | # Call <code>init()</code> on each SimObject. This provides the first opportunity to perform initializations that depend on ''all'' SimObjects being fully constructed. |
# Call <code>regStats()</code> on each SimObject. | # Call <code>regStats()</code> on each SimObject. | ||
| − | |||
# Complete initialization of SimObject state from a checkpoint or from scratch. | # Complete initialization of SimObject state from a checkpoint or from scratch. | ||
#* If restoring from a checkpoint, call <code>loadState(ckpt)</code> on each SimObject. The default implementation simply calls <code>unserialize()</code> 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 override <code>loadState()</code> to get other behaviors, e.g., doing other programmed initializations after <code>unserialize()</code>, or complaining if no checkpoint section is found. | #* If restoring from a checkpoint, call <code>loadState(ckpt)</code> on each SimObject. The default implementation simply calls <code>unserialize()</code> 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 override <code>loadState()</code> to get other behaviors, e.g., doing other programmed initializations after <code>unserialize()</code>, or complaining if no checkpoint section is found. | ||
#* If not restoring from a checkpoint, call <code>initState()</code> on each SimObject instead. This provides a hook for state initializations that are only required when ''not'' restoring from a checkpoint. | #* If not restoring from a checkpoint, call <code>initState()</code> 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, the switch CPU ports are connected in <code> BaseCPU::takeOverFrom</code> at this stage. | ||
# Later, the first time that the user script calls <code>simulate()</code>, call <code>startup()</code> on each SimObject. This is the point where SimObjects that do self-initiated processing should schedule internal events, since the value of <code>curTick</code> could change during unserialization. | # Later, the first time that the user script calls <code>simulate()</code>, call <code>startup()</code> on each SimObject. This is the point where SimObjects that do self-initiated processing should schedule internal events, since the value of <code>curTick</code> 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#Running | 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. | ||
| + | |||
| + | [[File:gem5_initialization_call_sequence.png|550px|thumb|center|gem5 Initialization Function Call Sequence]] | ||
====Header files to include==== | ====Header files to include==== | ||
Latest revision as of 16:49, 24 September 2012
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
SelforParent). - Dump the
config.inifile 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. - 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::takeOverFromat 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 ofcurTickcould 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.
