Hi Prathap, Check retryWaiting in Xbar. There we choose the port to go next when one or more ports had to wait. If you want to implement what you suggest you also have to perform a check in recvTimingReq to not just see if the layer is busy, but also check if the port asking is within budget.
Andreas From: Prathap Kolakkampadath <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Monday, 4 May 2015 22:56 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: Re: [gem5-users] Query regarding blocking cache slave port Hi Andreas, Thanks for your reply. I am trying to figure out how to implement this based on your inputs. Can you also please point out the data structures which maintains the queue in cross bar.? Thanks, Prathap On Mon, May 4, 2015 at 4:04 PM, Andreas Hansson <[email protected]<mailto:[email protected]>> wrote: Hi Prathap, The most sensible place to implement the arbitration is indeed in the crossbar which is conceptually part of the L2 cache. By default the crossbar uses First-Come First-Served, but you can change with not too much coding. The tricky bit in this case is to base the selection on MSHRs, since the crossbar has no such accounting. I would think the easiest is to add outstanding transaction counting per SlavePort in the crossbar, and then only let a port have X outstanding transactions. Overall this would be valuable functionality, so if you do code it up, please post a patch. It would be a great contribution. Andreas From: Prathap Kolakkampadath <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Monday, 4 May 2015 20:18 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: [gem5-users] Query regarding blocking cache slave port Hello All, I am simulating an ARM O3 multi-core system with private L1 cache and a Shared L2 cache. I am investigating the MSHR contention in the L2 cache. If cache has no free MSHRs, this Marks the access path of the cache as blocked and also sets the blocked flag in the slave interface.This means there won't be any further access to the L2 cache. Instead of blocking the L2 cache altogether, i would like to place a MSHR reservation to a selected core. So that requests from only selected core are blocked based on its respective MSHR utilization. I am not sure if this is feasible. Do L2 Bus has an arbitrator which can be modified to do this? Thanks, Prathap -- 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-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- 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-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
