On Wed, 26 Sep 2012, Andreas Hansson wrote:
I'm not too thrilled about this. Could you explain why we cannot rely on the
global time keeping here? I'm not understanding the issue...
You need to understand how ruby warms up the caches on a checkpoint
restore. The checkpoint records (address,value) pairs for all the
caches. On restore, before the actual simulation starts, ruby replays
these recorded pairs by making timing requests for these. Thus, the global
time moves ahead because of ruby's cache warm up. But since we are
restoring from a checkpoint, after the warm up is over, we restore the
global time.
RubySystem is now a clocked object. This means it stores a tick and a
cycle value, which are in the neighbourhood of the global tick value. But
even after the global tick value is restored, RubySystem object will still
hold the same tick and cycle values. Hence, the need for clock reset.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
