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. 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? Andreas On 06/11/2014 16:53, "Nilay Vaish" <[email protected]> wrote: >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 >> >> >> > -- 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
