It is not that simple.
The whole point is that the crossbar does any address interleaving, so
that it can be used both for memories and caches (or really any slave
downstream). Moreover, there is no need for a single level of crossbars to
actually have all addresses represented. It can be used to build trees,
diamonds, etc. See the HMC construction for example where we split
addresses across links, then quadrants, and finally to the vaults/channels.
We spent quite some time thinking about how to best represent this, and I
think the best option would actually be to use some form of sub system and
port-group type construct, perhaps combined with a more refined AddrRange.
There are a lot of challenges that need to be addressed though, and
previous whiteboard discussions have not yielded a design that actually
encompasses all the important use-cases.
It would be great to see a good design for this, but it¹s definitely not
obvious what it would be.
On 08/08/2017, 03:17, "gem5-dev on behalf of Gabe Black"
<gem5-dev-boun...@gem5.org on behalf of gabebl...@google.com> wrote:
>Hi folks. I notice that there's a fair bit of code in MemConfig.py which
>sets up a bank of memory objects to interleave memory accesses among
>themselves and collectively act as a single memory. This seems like
>something which should be bound up into a wrapping object, perhaps a
>RamBank SimObject, which would abstract the complexity of setting up the
>interleaving. There could be a specialized DramBank object which would
>get rid of the ugly issubclass() in create_mem_ctrl function.
>gem5-dev mailing list
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.
gem5-dev mailing list