<jorolf[m]>
I saw that a while back @ld_cd:matrix.org was working on an AXI RFC. Is that still being worked on?
frgo has joined #amaranth-lang
frgo has quit [Read error: Connection reset by peer]
frgo has joined #amaranth-lang
frgo has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
frgo has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
bai has joined #amaranth-lang
bai has quit [Client Quit]
bai_ has joined #amaranth-lang
AledCuda[m] has joined #amaranth-lang
<AledCuda[m]>
Yup
<AledCuda[m]>
Higher priority work took over for a while (etch tool shit the bed) but I've got a working draft of the interface/sig and CSR bridge stuff which I'm testing out with some peripherals at work
<AledCuda[m]>
Once I'm satisfied with it I'll write up an RFC
<AledCuda[m]>
Actually I did have a question here for anyone more familiar with the language internals here. Each of the axi signalling channels has semantics that map well onto amaranth streams. Someone a while back pointed out that it would be handy to have a method like .rstream/.wstream methods on lib.fifo.*. My understanding is that the lack of a correspondence between structs and lib.wiring signatures makes this impractical because you
<AledCuda[m]>
have multiple distinct signals that you'd need to pack into a single payload. Is this inference correct and still the case?
<zyp[m]>
it's not impractical, it's the way it's intended to work
<AledCuda[m]>
IE w_stream.payload = Cat(LAST, USER) but in a way that produces a StructLayout
<zyp[m]>
sure, you can do that
<whitequark[cis]>
lib.fifo hasn't been updated for lib.data and will probably get replaced wholesale with a new module
frgo_ has quit [Ping timeout: 248 seconds]
<whitequark[cis]>
the r_stream/w_stream methods are kind of a thing to tide us over until then
<AledCuda[m]>
Basically I'm looking to provide something similar for an AXI rfc
<zyp[m]>
I would consider using stream interfaces directly in the AXI interfaces instead of making stream gaskets
<whitequark[cis]>
yeah
<AledCuda[m]>
Hmm, I'll try and see if I can get that to play well with vendor IP integrators but I understand that's not a broader concern to the broader language
<AledCuda[m]>
Sorry I had convinced myself that was impossible
<zyp[m]>
I'd add that this is ugly, and if this becomes commonplace due to gaskets or whatever, it'd be good to have a kind of Cat that takes a layout and a dict of signals
<zyp[m]>
Unless we already have it and I just can't remember it
<AledCuda[m]>
I might end up writing something like that because an annoying number of the axi signals are optional
frgo has joined #amaranth-lang
<zyp[m]>
I guess it could be a method on data.Layout, so you could do e.g. interface.payload = payload_shape.aggregate({'data': data, 'last': last})