-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling resource name collisions inside a MemoryMap #20
Labels
Comments
Sounds good--I have missed this somehow.
I think the |
jfng
pushed a commit
to jfng/amaranth-soc
that referenced
this issue
Aug 31, 2020
Breaking changes: * MemoryMap.add_resource() now takes a mandatory ``name`` parameter. * MemoryMap.resources() now returns a ``resource, name, (start, end)`` tuple. * MemoryMap.all_resources() and MemoryMap.find_resource() return an instance of ResourceInfo describing the resource and its assigned name and address range, instead of a tuple. * Freezing a memory map now prevents the further addition of *any* resource or window, instead of only the ones that require an extension of the memory map address bits. Allowing these could prevent us from detecting name conflicts in some cases. Other changes: * MemoryMap.__init__() now takes an optional ``name`` parameter, which is then visible as a property. * csr.Multiplexer, csr.Decoder, WishboneCSRBridge and wishbone.Decoder now take an optional ``name`` parameter in __init__(), which is passed to their underlying memory map. Fixes amaranth-lang#20.
jfng
pushed a commit
to jfng/amaranth-soc
that referenced
this issue
Sep 1, 2020
Breaking changes: * MemoryMap.all_resources() and MemoryMap.find_resource() return an instance of ResourceInfo describing the resource and its assigned name and address range, instead of a tuple. Fixes amaranth-lang#20.
jfng
pushed a commit
that referenced
this issue
Oct 29, 2021
Breaking changes: * MemoryMap.all_resources() and MemoryMap.find_resource() return an instance of ResourceInfo describing the resource and its assigned name and address range, instead of a tuple. Fixes #20.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dumping CSR names from a
MemoryMap
by iterating over.all_resources()
is subject to name collisions.These can happen in two scenarios:
In this case, we could add a
name
attribute toMemoryMap
. Each window would then have a namespace for its resources. Resolving the full resource name would be the responsibility of the BSP generator, by walking through the memory hierarchy.The result could look like this :
In this case, I don't see an easy way to disambiguate the two names. The BSP generator would have to detect this and throw an error.
The text was updated successfully, but these errors were encountered: