Hi Andreas,
Thank-you for this information. I will have to digest it, but will get
back with you.
Cheers,
Roger
On 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
fear
2) 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 the
interconnect (i.e. Actually write to different addresses), and let the OS
handle 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 redundancy
and copy on write (cow) failure modes. Blacklist failed memory areas and
create 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
you
want 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
that
is 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 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
--
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
