[DanielKellerM]

Stacked on #6 (fix-strb), since that is the revision gwaihir uses.

The read/write demux in axi_to_obi only sends AR to the read converter and AW/W to the write converter, but the unused channels were still connected. Their ready/valid paths coupled the two converters, so a manager whose R ready depends on its W ready (iDMA does this) closes a combinational loop through the converter. SpyGlass reports it as CombLoop on the gwaihir mem tiles (iDMA -> axi_to_obi). The loop can never be sensitized, but it is a real gate cycle.

This ties off the dead channels (read converter AW/W/B, write converter AR) and, when UseAtop is off, the write converter R. No change in area or latency.

Checked with a lockstep Questa 2026.1 testbench, old vs new module driven by axi_rand_master, with every output compared each cycle: 0 mismatches for UseAtop=0/1 at AXI 32/64 bit, 3000 ATOPs in the UseAtop=1 runs. The Verilator lint warnings are the same as before. Together with the matching iDMA fix, gwaihir's mem_tile_small/mem_tile_large have 0 CombLoop.

The new assertion fires if an ATOP reaches a converter without UseAtop. Before, such an ATOP was done as a plain write and returned a junk R. Now its R is dropped.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[DanielKellerM]

@Lore0599 @colluca need review here, solves combinational loop in mem-tile

[Lore0599]

I'm not the official maintainer of this repo but let me add few comments below.
In general I think the fixes you've done solve the comb loop.
My concerns are the following:

1. To my understanding, it makes sense to tie off the R channels (and W) in your specific situation (DMA comb loop). However, when we have ATOP, the R path on the write adapter is actually used. Therefore, don't we have the comb loop risk again?
2. For the reason above, I think it might make sense to add a spill register to cut the comb loop. Since this has a HW cost, and I think it's not a necessary cost in case of no ATOP support, I added it only in the atomic path.

In general, I have the feeling that R->W dependency is not really AXI compliant, therefore the coupling done by the DMA is not the best, even though I don't have a solution to it at the moment (except adding huge buffers in the DMA).
Perhaps in the ATOP support is less likely that the manager couples R-W, however I still think it's better to avoid the comb loop here instead of relying on the endpoint behaviour.

@micprog @colluca @DanielKellerM I would like to have your opinion regarding the comment above.