[libre-riscv-dev] 53000 as ME for libre-riscv - bus interfaces?
Samuel Falvo II
sam.falvo at gmail.com
Sun May 5 23:50:03 BST 2019
On Sun, May 5, 2019 at 1:39 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> yes. just passing in the class (usually done as kls) is one way: let
> the module that uses it instantiate an instance. or, create a base
> class where the *deriver* is required to add the missing ifu
In other projects, I've also passed entire modules by reference this
way as well. That's another option, and might be simpler in this case
(as long as the module implements and exports the required classes).
The common theme here is dependency injection. :)
> class Interface(Record):
> def __init__(self, width):
> self.addr = Signal(width)
> self.data = Signal(width)
Thanks for the heads up. That's quite regrettable. Thankfully,
easily worked around.
> whitequark absolutely and pathologically insists that Record is an
> ordered sequence of *BITS* and categorically and pathologically will
> not accept that everyone that i have spoken to about Record treats it
> as an ordered sequence of *items*.
The most obvious application of this is matched pairs of structured
ports, such as using it to *derive* a corresponding slave interface
from a master interface automatically. For example, in TileLink and
AXI, masters are identified by a globally unique or transaction IDs,
respectively. How many bits you devote to these is not necessarily up
to the system integrator (you're always free to add bits at the
master/INTERCON edge, but you can never take bits away), and is not
specified by the respective standards, which makes interfacing
masters and slaves with disparate ID widths an "interesting"
challenge. Without the ability to introspect into the record to
determine this signal width, you end up having to distribute this
number throughout your design manually, which is a source of
With per-item records, this becomes fully automatic.
I guess the nmigen powers that be have to feel their own pain before
1. Such an ID is optional with Wishbone, and thus rarely used, since
the CYC_O the INTERCON fabric can synthesize its own internal IDs
based on which master CYC_O signal is asserted. IOW, TileLink and AXI
replies are "source routed", while Wishbone INTERCONs act more like an
Ethernet switch (geographically routed). Both are circuit-switched,
but the latter reserves the responsibility of ID assignment
exclusively to the INTERCON component. The disadvantage to Wishbone's
approach is that it enforces in-order completion of bus requests.
However, AXI4 abandoned AXI3's out of order support, so this is
apparently not such a bad thing. Also, one could bend the Wishbone
rules a bit by relying on TGD_I() tag bits to support retiring
requests out-of-order. There's no verbiage in the B4 specs which
explicitly forbids this to my knowledge.
Samuel A. Falvo II
More information about the libre-riscv-dev