As I suggested before, we will keep the timing accesses to ruby and the
dram ctrl would be accessed using functional accesses.
--
Nilay
On Sun, 9 Nov 2014, Andreas Hansson via gem5-dev wrote:
Hi Brad,
Thanks a lot for the clarification.
It seems the cleanest way (although that is probably requiring a lot of
work), would be to do this playback without any timing involved, e.g.
using atomic accesses and ignoring all return values, and doing so just
after all other startup activity is done, perhaps in a new ??playbackState??
or something along those lines.
In any case, for the short term, let me know if you need any help with a
work-around Nilay. I??d prefer to discard the patch you currently have on
RB and solve it some other way.
Thanks,
Andreas
On 11/6/14, 6:10 PM, "Beckmann, Brad via gem5-dev" <[email protected]>
wrote:
Andreas, we record the "owner" of the cache block in the trace. This
methodology simplifies the configuration dependencies on the checkpoint
and has worked well for Ruby for 15 years. There is actually an old
paper from MIT that describes a more complete way of recording the owner
of a cache block (I don't recall the author). It is quite a bit more
complicated than what we do in Ruby today.
Brad
-----Original Message-----
From: gem5-dev [mailto:[email protected]] On Behalf Of Andreas
Hansson via gem5-dev
Sent: Thursday, November 06, 2014 9:49 AM
To: Nilay Vaish
Cc: Default
Subject: Re: [gem5-dev] Review Request 2469: mem: dram ctrl: correct
errors due to busBusyUntil variable
Hi Nilay,
It seem like a bit of a hack to do timing within Ruby and functional to
the memory, but it will probably serve as a work-around.
I??m actually intrigued now how we do this recording/replaying of the
cache traces. Does it really make sense to do it this way? If the cache
config is the same, we could have just saved the state. If the config is
different, how would we know what to play back where? Does it really
restore to any sensible state?
Andreas
On 06/11/2014 17:45, "Nilay Vaish" <[email protected]> wrote:
On Thu, 6 Nov 2014, Andreas Hansson wrote:
Hi Nilay,
I would really not like us to introduce yet another step in the
initialisation process unless it is absolutely necessary.
The steps done in the DRAM controller relies on curTick being set
correctly, and to the best of my knowledge the first opportunity to do
this is startup. I would prefer to stick to the rule that only
functional transactions are allowed up till this point.
We will not be able to load the checkpointed state only with functional
reads and writes since functional accesses do not update coherence
states in ruby controllers. But it seems we can limit timing accesses
to the ruby portion and perform functional accesses to the dram. This
should allow use to keep the dram ctrl same as it is now.
I think the best solution would be if Ruby would load its state in
loadState/unserialize without using timing transactions, but I do not
have a good suggestion for how to make this happen. Additionally, how
do we even know what transactions to play back when it is done in
startup today?
We just issue read for all the addresses that are part of the
checkpointed cache state.
--
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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
