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
