wishbone: A proposal to add Interconnect & related SoC building blocks #6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On this pull request, I propose new modules to introduce shared bus interconnection (as described in Section 8.2.3 of Wishbone B4) to this SoC building library and add some "shortcuts" for making such interconnection. This includes:
wishbone.bus.Arbiter
: A module for bus arbitration. Originally (commits before 976cef4), my proposal would work only for standard handshake protocol without block reads/writes (usage of LOCK), pipelining (usage of STALL) or registed feedbacks (usage of CTI and BTE). As soon as I read @jfng's proposal (wishbone.bus: add Arbiter. #3), I realised the importance of including those features and I decided to adopt his design. Currently, the difference between our proposals is that mine separates the Round Robin arbitration/scheduling method from theArbiter
class, and makes it a standalone scheduler (scheduler.RoundRobin
). See below for details.scheduler.RoundRobin
: A module to implement a Round Robin scheduler, which is mainly used for bus arbitration inwishbone.bus.Arbiter
. Originally (commits before 976cef4), my proposal makes the scheduler ignore the initiator if it is not requesting for access to the interconnect shared bus. But @jfng's unit tests indicated that the arbiter should allow the masters to take turn to continue the transaction cycle with their targeted slave by locking while keeping its request, meaning the next master has to be granted access on every clock. Thus, I removed theIf(~self.request[i])
from my code and made it work with theArbiter
adopted from @jfng.wishbone.bus.InterconnectShared
: A module for basic shared bus interconnection. For initialisation, it accepts a list of initiators (MASTERs) and a list of targets (SLAVEs), as well as the parameters for the shared bus (e.g. address & data widths, granularity), for theArbiter
on the MASTERs (e.g. arbitration method) and for theDecoder
on the SLAVEs (e.g. address alignment). It instantiates the shared Wishbone bus, anArbiter
and aDecoder
using these parameters, and connect the two to the shared bus.wishbone.SRAM
: A module for a simple readable or read/writable SRAM. Its memory read and write enable strobes follow the logics for READ and WRITE operations according to the Wishbone specification (Sections 3.2.1 and 3.2.3) respectively. Currently, no unit tests have been written for this module.Better docstrings will be added ASAP. Thank you.