We want to keep the checkpoint state for caches independent of the
protocol being used. To reconstruct the state of caches, therefore, we
replay memory accesses to the addresses present in the checkpoint. This
can only be done after every component is in a state where they are ready
to begin simulation. Earlier we could ensure this within ruby. But
now that we are using dram ctrl, we would need a new stage.
--
Nilay
On Thu, 6 Nov 2014, Andreas Hansson wrote:
Hi Nilay,
Apologies for my limited insight in how Ruby restores from a checkpoint,
but could we not avoid injecting any packets all together? Is there a
fundamental reason why this is needed? Could we not let the various
objects be responsible for their own portion of the checkpoint state?
Andreas
On 06/11/2014 16:32, "Nilay Vaish" <[email protected]> wrote:
Ok, in that case, I would add one more stage to the initialization phase
so as to allow ruby to restore from a checkpoint.
--
Nilay
On Thu, 6 Nov 2014, Andreas Hansson wrote:
Hi Nilay,
I see.
The reason that it is set in startup is due to the checkpoints.
I would argue that we should not allow any transactions to be issued in
startup. Would that work?
Andreas
On 06/11/2014 15:55, "Nilay Vaish" <[email protected]> wrote:
On Thu, 6 Nov 2014, Andreas Hansson wrote:
On Oct. 31, 2014, 10:21 p.m., Nilay Vaish wrote:
Andreas, please review this patch. I would like the ruby-related
patches
be committed soon as possible.
I'm surprised this is needed. The busBusyUntil should be initialised
to
a sufficiently high value that this would never occur.
Could you elaborate on when the problem arises (under what
conditions)?
I encountered problems when simulating with ruby and dram ctrl and
starting from a checkpoint. Ruby issues memory requests in its
startup()
function when loading a checkpoint. It seems that the startup() was
not
called on the dram ctrl when ruby started issuing requests. This means
that busBusyUntil was at 0 to begin with. Since busBusyUntil is
unsigned,
subtracting a higher value from it results in a very large tick value.
This results in a dead lock. I added the checks as shown in the patch
to
avoid subtracting a larger number from a smaller number. This resolved
the problem.
As of now I am unsure if this is right way to solve the problem. Is it
possible to move the initialization of busBusyUntil to init() and
unserialize()? What's the earliest stage in a sim object
initialization
phase that can call curTick()?
--
Nilay
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
