Hi Andreas,I would like to pursue the address decoding approach and take the plunge into a bigger physical address space.
This is the first time I will be looking at the code and am wondering where would be a good place to start. Is there a specification? I realize its a lot of code and want to be comfortable I am catching all of the options.
I am thinking it may be advantageous to use the ARM processor in this case. It seems there are two master CPU ports, one for instructions, the other for data.
Thank-you for you help. Cheers, RogerOn Tue, 15 Apr 2014 16:54:10 -0600, Roger Smith <[email protected]> wrote:
Hi Andreas,Thank-you for this information. I will have to digest it, but will get back with you.Cheers, RogerOn Tue, 15 Apr 2014 16:30:11 -0600, Andreas Hansson <[email protected]> wrote:Hi Roger,I think you¹ll struggle to accomplish anything like this with the existing address mapper. The memories in gem5 (all inheriting from AbstractMemory),presents themselves to the system in two ways: 1) Through an address decoding process done by the interconnect. This would be easy to change. 2) Through a direct function-call API where a global interval-tree keeps track of what memory corresponds to what address. The latter is used for debugging/introspection etc.The two views are kept in sync, and if you start to tamper with 1), I fear2) will quickly break. I would suspect your best bet is to either take the plunge and have a bigger physical address space, do the replication ³properly² in theinterconnect (i.e. Actually write to different addresses), and let the OShandle the VA->PA mapping.The other extreme option is to hide it within the AbstractMemory somehow.I am not sure what that would look like, and it depends on how much you want to expose to the OS etc. Andreas On 4/15/14, 7:21 PM, "Roger Smith" <[email protected]> wrote:Hi Andreas, I would like to dynamically configure memory in dual, triple redundancyand copy on write (cow) failure modes. Blacklist failed memory areas andcreate memory sandboxes at the interconnect level. Thanks, Roger On Tue, 15 Apr 2014 11:32:15 -0600, Andreas Hansson <[email protected]> wrote:Hi Roger,Could you perhaps shed some light on the bigger picture here. Why do youwant to re-map a slave? You are right about the fact that ARM and Ruby does not work. In general,the classic memory system has a broader support. The crossbar model thatis part of the classic memory system can be used to build quite elaborate interconnect topologies, so hopefully that is enough. Thanks, Andreas On 15/04/2014 18:13, "Roger Smith" <[email protected]> wrote:I have a newby question. I would like to modify the Interconnect module(s) located between the CPU and Slave module to remap the Slave module address space. The diagram showing these modules can be seen in the ARM gem5 Tutorial, Bischoff & Hansson, slide 70, titled Ports, Masters, and Slaves. I appears there a couple of paths. The first is to modify the AddrMapper class the second is to modify or write a Ruby script. It seems there are some issues with Ruby and ARM non-contiguous memory. Any suggestions on a place to start and route to take? Thanks, Roger -- _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev-- IMPORTANT NOTICE: The contents of this email and any attachments areconfidential and may also be privileged. If you are not the intendedrecipient, please notify the sender immediately and do not disclose thecontents 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
