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
