Asymmetric axi_to_reg_v2 (64-bit AXI, 32-bit REG) throttles burst transactions

[cousteaulecommandant]

When using axi_to_reg_v2 to adapt a 64-bit AXI interface to a 32-bit Register interface, burst transactions are throttled to 67% capacity (one 64-bit AXI word / two 32-bit REG words every 3 clock cycles instead of 2). I would have expected the REG side to be busy 100% of the time and the AXI side to be busy one out of every two clock cycles.
This doesn't happen if both sides of the converter are the same width (e.g. both 32 bits) - in that case, it achieves a performance of 100% (one word per clock cycle).

                       Expected:                 Obtained:
                        ___________________       _______________________
axi_req_i.w_valid   ___|                      ___|                       
                        _   _   _   _   _         _     _     _     _    
axi_rsp_o.w_ready   ___| |_| |_| |_| |_| |_   ___| |___| |___| |___| |___
                        ___________________       ___   ___   ___   ___  
reg_req_o.valid     ___|                      ___|   |_|   |_|   |_|   |_

I suspect that the culprit is this BufDepth parameter for axi_to_detailed_mem being fixed to 1; I tried changing it to 2 and that seems to provide maximum efficiency (no throttling), although I'm not sure this is right to do or if it breaks the behavior of the module (maybe it was fixed to 1 for a reason); I didn't experiment enough or look much into the code to figure out if the behavior is correct with this change.

register_interface/src/axi_to_reg_v2.sv

Line 80 in 8e8c209

.BufDepth ( 32'd1 ),

Would changing this parameter solve the issue? Which value should it take? I suspect 2 is not a "one size fits all" solution and that other cases (e.g. 128-bit AXI and 32-bit REG, a 4:1 ratio) will require different values.

[phsauter]

Thanks for the issue, thinking it through it seems you are correct.
The axi_to_detailed_mem comments even state: Depth of memory response buffer. This should be equal to the memory response latency.
Here the 'memory latency' is essentially how many 32-bit transactions we need until we have the full AXI-request covered, ie for 64-bit axi it is 2 and for 128 it is 4.
I think the intent was to handle this via NumBanks but as far as I can tell this doesn't actually alter the AXI 'frontend' so you still get this stall cycle.
I will investigate this further.