Michael Rogenmoser

> We do not have a testbench for this module, right? #248 adds a banked variant using `axi_to_mem`, as well as a testbench for the banked variant, consequently also testing...

Merged with #244 and #248

>- A request type MUST end with `X_req_t`. >- A response type MUST end with `X_rsp_t`. Would it make sense to use `X_resp_t` for the response types? The main rationale...

I recently came across this which might implement similar functionality: https://github.com/pulp-platform/axi/blob/db457aa8d8996d87ca72486a9b15873042e04d38/src/axi_test.sv#L2195

If I'm not completely mistaken, the file you link currently instantiates the following module from a separate repository: https://github.com/pulp-platform/axi_node/blob/a29a69a543e96d0c9f79ea9c7df20580b3da5002/src/axi_node_wrap_with_slices.sv When using the [`axi_xbar` module](https://github.com/pulp-platform/axi/blob/master/src/axi_xbar.sv), this should automatically use the [`axi_demux`...

Should be combinational, i.e. no cycle latency at all, but please check the [documentation](https://github.com/pulp-platform/axi/blob/master/doc/axi_xbar.md#pipelining-and-latency) for how to use the `LatencyMode` parameter.

requires https://github.com/pulp-platform/common_verification/pull/4

This is definitely an enhancement proposal. @WRoenninger's reasoning of course makes sense, but there are some performance implications, e.g. for large dma transfers across interleaved slaves that are far away...

I was unaware of #153, but aligning to this makes sense, thanks for pointing me in that direction. I agree that limiting the breaking changes to one release is the...

Linking to #33