AXI_XBAR pipeline

[WRoenninger]

This adds a change to the axi_demux implementation which has the benefit that the crossing AXI busses inside of axi_xbar can now be pipelined. The issue was that the axi_demux could forward multiple AWs to different master ports of the module. This then has the effect, that Ws are forwarded in the same sequence. However combined with an axi_mux this could lead to deadlocks, if the AWs where stalled for example due to pipelining. This PR fixes this issue by preventing AWs to be forwared to a different master port as long as there are still Ws in flight to another.

Changelog:

• tb_axi_xbar: Add parameters, make more configurable for ci.
• axi_demux: Remove FIFO between AW and W channel, is now a register plus counter. Prevents AWs to be emmitted downstream to a different master port as long as Ws are still in flight to another. This prevents deadlock, if there is stalling downstream.
• axi_xbar: Add parameter PipelineStages to axi_pkg::xbar_cfg_t. This adds axi_multicuts in the crossed connections in the xbar between the demuxes and muxes.
• axi_pkg: Add documentation to xbar_cfg_t.

[WRoenninger]

~~Removed now the Cfg struct of axi_xbar and the defintion in axi_pkg. This resulted in the same removal being done for axi_lite_xbar.~~

Edit: This was reverted to keep compatibility for existing code for now.

[WRoenninger]

Rebased onto current master, also changed around the Bender dependencies to match current tags.

[WRoenninger]

Rebased onto current master for ci fix by #129.

[WRoenninger]

@accuminium There seems to be an issue with the build and deploy ci, where there is some lock failure between the (push) and (pull_request) scripts.

[andreaskurth]

@accuminium There seems to be an issue with the build and deploy ci, where there is some lock failure between the (push) and (pull_request) scripts.

Thanks, I also noticed that. In a PR, each of the CI jobs should actually only run once (triggered by the pull_request event, and not by push). The push event is relevant only outside PRs. But I have not yet spent the time to figure out how to define this condition. Please feel free to open a PR that fixes this. The workaround for now is to manually restart the build-and-deploy job when it fails due to a conflict with the other instance.

[thommythomaso]

Replaced by #268. Closed.