gem5/src/sim/root.hh

117 lines
3.9 KiB
C++
Raw Normal View History

Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided.
2011-01-19 20:48:00 +01:00
/*
2011-06-02 23:36:35 +02:00
* Copyright (c) 2011 Advanced Micro Devices, Inc.
Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided.
2011-01-19 20:48:00 +01:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met: redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer;
* redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution;
* neither the name of the copyright holders nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Authors: Gabe Black
*/
/**
* @file This file defines the Root simobject and the methods used to control
* the time syncing mechanism provided through it.
*
* Time syncing prevents simulated time from passing faster than real time. It
* works by scheduling a periodic event that checks to see if its simulated
* period is shorter than its real period. If it is, it stalls the simulation
* until they're equal.
*/
#ifndef __SIM_ROOT_HH__
#define __SIM_ROOT_HH__
#include "base/time.hh"
#include "params/Root.hh"
#include "sim/eventq.hh"
#include "sim/sim_object.hh"
class Root : public SimObject
{
private:
static Root *_root;
protected:
bool _enabled;
Time _period;
Tick _periodTick;
Time _spinThreshold;
Time lastTime;
void timeSync();
EventWrapper<Root, &Root::timeSync> syncEvent;
friend class EventWrapper<Root, &Root::timeSync>;
public:
/**
* Use this function to get a pointer to the single Root object in the
* simulation. This function asserts that such an object has actual been
* constructed to avoid having to perform that check everywhere the root
* is used. This is to allow calling the functions below.
*
* @return Pointer to the single root object.
*/
static Root *
root()
{
assert(_root);
return _root;
}
public:
/// Check whether time syncing is enabled.
bool timeSyncEnabled() const { return _enabled; }
/// Retrieve the period for the sync event.
const Time timeSyncPeriod() const { return _period; }
/// Retrieve the threshold for time remaining to spin wait.
const Time timeSyncSpinThreshold() const { return _spinThreshold; }
/// Enable or disable time syncing.
void timeSyncEnable(bool en);
/// Configure the period for time sync events.
void timeSyncPeriod(Time newPeriod);
/// Set the threshold for time remaining to spin wait.
void timeSyncSpinThreshold(Time newThreshold);
typedef RootParams Params;
const Params *
params() const
{
return dynamic_cast<const Params *>(_params);
}
Root(Params *p);
/** Schedule the timesync event at loadState() so that curTick is correct
*/
void loadState(Checkpoint *cp);
/** Schedule the timesync event at initState() when not unserializing
*/
void initState();
Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided.
2011-01-19 20:48:00 +01:00
};
#endif // __SIM_ROOT_HH__