[libre-riscv-dev] 53000 as ME for libre-riscv - bus interfaces?

[Luke Kenneth Casson Leighton]

On Sun, May 5, 2019 at 11:50 PM Samuel Falvo II <sam.falvo at gmail.com> wrote:
>
> 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).

 yehyeh.  oh wait... a *python* module by reference?  haha, yeah that works :)

 hmm... then... i would say you could use module.__all__ to check if
it has the required classes... however it's often just as simple to go
"y'know what? if user ! implement, let exception happen!"

> The common theme here is dependency injection.  :)
>
> > class Interface(Record):
> >     def __init__(self, width):
> >         Record.__init__(self)
> >         self.addr = Signal(width)
> >         self.data = Signal(width)
>
> Thanks for the heads up.  That's quite regrettable.  Thankfully,
> easily worked around.

 kiinda, yeh.

> 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.

 [smells to me like, "have a common class for both, with a boolean
constructor option to select mst/slave"]

>  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[1], which makes interfacing
> masters and slaves with disparate ID widths an "interesting"
> challenge.

 oh, whoops.  which begs the question: what were the designers of that
code thinking by not making the ID width parameterisable??

>  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
> accounting errors.

 *sigh* yeh width disparity matching as a warning / nmigen-lint would be nice.

> With per-item records, this becomes fully automatic.

 ta-daaaa

> I guess the nmigen powers that be have to feel their own pain before
> they'll understand.

 *sigh*, yep....

> 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).

 interesting...