AXI user signals in axi_node_intf_wrap

[Steinegger]

I noticed an issue with the axi_node_intf_wrap module instantiated as i_axi_xbarin the verilator model ariane_testharness.sv. I expanded the axi user port in the .axi_req_o ( axi_ariane_req ), signal coming from the ariane module to 134 bits to send additional information to one of the axi modules as part of the AW and AR bus. I also updated the src/util/axi_*.sv files to not set the user signals to 0. However, it turns out the signal isn't propagated properly for the AR bus, whereas it is working mostly fine for AW. I traced the signals and it seems that the culprit is the i_axi_xbar instance of axi_node_intf_wrap. The screenshot shows the axi signals coming from the ariane module and entering the slave interface of the i_axi_xbar instance and the output of the 9 master interfaces. The signal is propagated properly for the AW port but not for the AR port

This happens primarily with the ariane_testharness.sv, thus the Verilator model. I didn't confirm it for what's put on the FPGA, but since the ariane_xilinx.sv file uses a similarily named axi_node_wrap_with_slices I suspect a similar issue there.

I opened an issue here since the axi_node repo seems to be archives, so a possible solution for cva6 would be to transition to the succeeding module

[zarubaf]

Unfortunately, the SoC in this project still utilizes a relatively old AXI infrastructure. The axi_node has now been deprecated and replaced by new infrastructure. We still need to update all components to the latest version (probably as soon as the AXI repository reaches a stable version number).

That said, I think that the axi_node was never tested with different user widths (we always had this hard-coded to 1). I suspect that there is some size mismatch in one of the components assignments. Theoretically speaking the user signal should be routed similarly to other transaction properties (such as size, len, etc.) and it should be possible to trace this through the xbar.

I opened an issue here since the axi_node repo seems to be archives, so a possible solution for cva6 would be to transition to the succeeding module

Exactly! Unfortunately, the update will likely pull-in many other changes that want to be well tested.

[Steinegger]

Theoretically speaking the user signal should be routed similarly to other transaction properties (such as size, len, etc.) and it should be possible to trace this through the xbar.

Yes, I looked at that, but I couldn't timely pin-point the location where the user-signal got lost.

Exactly! Unfortunately, the update will likely pull-in many other changes that want to be well tested.

This makes sense of course. We temporarily worked around it in the testbench by not passing it through the IPs and using an axi xilinx ip on the fpga.

Thanks for the clarification and details on the situation

[MikeOpenHWGroup]

Thanks for your insight @zarubaf.

Hi @Steinegger, thanks for your interest in CVA6. This issue has not been updated in more than two years, so I will assume it is resolved and will close this issue. If you are still having trouble, please feel free to open another.