-
Notifications
You must be signed in to change notification settings - Fork 33
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
Add support for extending the address space of a memory map #7
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7 +/- ##
==========================================
- Coverage 100% 99.59% -0.41%
==========================================
Files 4 4
Lines 436 493 +57
Branches 95 107 +12
==========================================
+ Hits 436 491 +55
- Misses 0 1 +1
- Partials 0 1 +1
Continue to review full report at Codecov.
|
I've cherry-picked 7f27d90 since it's just what we discussed and it seems correct. For the other commit, could you explain why you made the memory map externally assignable, rather than created by the parent object? |
Thanks !
Let's consider the case where the
We have a problem: the updated A solution is to lazily create the bus interface, only when it is requested from the multiplexer. It would then have up-to-date record fields. The memory map is freezed at the same time. In order to do this, the memory map has to be created by the multiplexer before the bus interface. The multiplexer adds resources to the map, and uses it to create the bus interface, once requested. I favored external assignation over passing the memory map to |
Thanks for the explanation. I agree there is no better way to do this. Please amend the commit to include the rationale, and feel free to merge it once it's done. |
fa244cd
to
6e96c89
Compare
Before this commit, the bus interface of a Decoder or a Multiplexer would be created during __init__. A bus interface would always be tied to an underlying memory map. After this commit, the following changes are introduced: * The bus interface of a Decoder (or a Multiplexer) is lazily created upon request. This allows the record fields of the bus interface to be up-to-date with any address space extension that may have occured. * The memory_map attribute of a bus interface is no longer assigned during __init__. It is instead assigned externally at a later time. Decoupling the memory map from the bus interface allows a Decoder (or a Multiplexer) to first create the memory map, extend it, and then use it to create the bus interface, once requested. * Decoder.add(extend=True) (or Multiplexer.add) can be used to add a window (or resource) that would otherwise not fit inside its underlying memory map.
6e96c89
to
e583fb1
Compare
The semantics for adding resources to a MemoryMap has changed in amaranth-soc with the addition of support for dynamically extending the address space of a memory map: amaranth-lang/amaranth-soc#7 This PR brings the Luna WishboneRAM and WishboneROM peripherals up to date with the new semantics.
The semantics for adding resources to a MemoryMap has changed in amaranth-soc with the addition of support for dynamically extending the address space of a memory map: amaranth-lang/amaranth-soc#7 This PR brings the Luna WishboneRAM and WishboneROM peripherals up to date with the new semantics.
This PR adds support for extending the address space of a
MemoryMap
, after it has been instantiated.Use case
Before this PR, the
addr_width
parameter of acsr.Multiplexer
would be the definitive address width of its underlying memory map.This is inconvenient, because it forces the user to be aware of the size and address of each
csr.Element
that will be added to the multiplexer upfront.This PR allows the address space covered by the
csr.Multiplexer
to be extended as resources are added to it.The following primitives can support this use case:
csr.Multiplexer
csr.Decoder
wishbone.Decoder
Contents
nmigen_soc.memory
nmigen_soc.csr
andnmigen_soc.wishbone
to the updated API