08:50 <maikmerten[m]> <whitequark[cis]> "the only thing that i really..." <- thanks for having a look. I guess this is easy to fix ;-)

17:43 <AledCuda[m]> API Design question, AXI has transaction IDs which allow results to be returned out of order, their width is implementation defined. Currently I have an ID feature:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZjvRJuDegfSBIhzfZsikMwHY>)

17:43 <AledCuda[m]> should I drop the feature and just have id_width in the signature

17:44 <AledCuda[m]> (AXI also has user defined signaling in each of the channels so the same question applies there)

17:45 <AledCuda[m]> (docstrings still wip obviously)

17:47 <AledCuda[m]> https://developer.arm.com/documentation/ihi0022/latest/

17:53 <tpw_rules> i'm not sure if it's version dependent but afaik id is mandatory

17:54 <tpw_rules> i tried ignoring it on cyclone v and just locked up the bus

17:54 <tpw_rules> also afaik the data_width can be much greater than 64

17:56 <AledCuda[m]> It is optional from the controller side

17:57 <AledCuda[m]> Yeah that docstring is out of date

17:57 <AledCuda[m]> it goes up to 2048

17:57 <AledCuda[m]> and it is optional on both ends in AXI4-Lite

17:58 <AledCuda[m]> Just realized the spec I linked is not 5 only, this is old but has the axi4 stuff: http://www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf

18:00 <AledCuda[m]> If you want to bridge to a peripheral that does not support ID and the controller does, the interconnect needs to do ID reflection which is relatively straightforward

18:00 <tpw_rules> i had ID mandatory with width > 0 and the ability to specify each of the user widths independently

18:01 <tpw_rules> which is how i needed on the cyclone v as it only had user data on aw and ar

18:02 <tpw_rules> (but it treated a user data of 0 width as not present in the interface)

18:02 <tpw_rules> s/interface/signature/

18:02 <tpw_rules> i'm not sure if those are right but it's what i did

18:02 <tpw_rules> i also made 5 sub interfaces for each stream which am sure is right

18:03 <tpw_rules> though the new payload attribute of streams will make a lot of dots...

18:03 <AledCuda[m]> You mean you split the channels into their own interfaces?

18:03 <tpw_rules> yes

18:04 <tpw_rules> they are five independent streams. i of course have them bundled up into one main signature

18:04 <tpw_rules> but that main signature just has five stream signatures as members

18:04 <AledCuda[m]> Hmm

18:04 <AledCuda[m]> yeah I'm taking a look

18:05 <tpw_rules> do you use anything in particular to template or set up docstrings?

18:06 <AledCuda[m]> no

18:06 <tpw_rules> you just do them by hand? numpy style?

18:06 <AledCuda[m]> I just copied the wishbone file and have been file

18:06 <AledCuda[m]> yeah

18:06 <tpw_rules> ah

18:06 <AledCuda[m]> s/file/editing

18:06 <AledCuda[m]> numpy style is the standard for amaranth I believe

18:06 <tpw_rules> yeah

18:08 <AledCuda[m]> I do have some concerns with splitting up the signature in terms of name mangling and compatibility with other tools (in my case vivado)

18:10 <tpw_rules> i just did that algorithmically and used that to set up an instance

18:12 <tpw_rules> might end up slightly weirder with real amaranth streams

18:12 <tpw_rules> https://github.com/tpwrules/papa_fpga/blob/7ac50706c51896b3e24c6e0826964cfca0867623/design/amaranth_top/amaranth_top/cyclone_v_hps.py#L26

18:13 <tpw_rules> https://github.com/tpwrules/papa_fpga/blob/7ac50706c51896b3e24c6e0826964cfca0867623/design/amaranth_top/amaranth_top/cyclone_v_hps.py#L108

18:14 <tpw_rules> there is probably scope for a method on the combo interface which creates one that's glued together but i don't think it would want to be common in amaranth code, only for connecting to other things. otherwise all the stream abstractions go away