RoCC: io.mem.req.ready stuck

**Type of issue**: bug report

**Impact**: rocc memory interface

```

logic[15:0] cnt;
localparam BASE = 32'h60010000;

assign rocc_cmd_ready = 1'b1;

assign rocc_mem_s1_kill = 1'b0;
assign rocc_mem_s2_kill = 1'b0;

assign rocc_busy = 1'b0;
assign rocc_interrupt = 1'b0;

assign rocc_fpu_req_valid = 1'b0;
assign rocc_fpu_resp_ready = 1'b1;

always @(posedge clock or posedge reset) begin
if(reset) begin
rocc_mem_req_valid <= 1'd0;
end
else begin
if(rocc_resp_valid & rocc_resp_ready) begin
rocc_mem_req_valid <= 1'd1;
rocc_mem_req_bits_addr <= BASE;
rocc_mem_req_bits_tag <= cnt[5:0];
rocc_mem_req_bits_cmd <= 1;
rocc_mem_req_bits_size <= 3;
rocc_mem_req_bits_signed <= 0;
rocc_mem_req_bits_phys <= 0;
rocc_mem_req_bits_no_alloc <= 0;
rocc_mem_req_bits_dprv <= 3;
end
else if(rocc_mem_req_valid && rocc_mem_req_ready) begin
cnt <= cnt + 1;
if(cnt < 1024) begin
rocc_mem_req_bits_addr <= BASE + cnt * 8;
end
else begin
rocc_mem_req_valid <= 1'd0;
end
end
end
end

/* Accumulate rs1 and rs2 into an accumulator */
reg [xLen-1:0] acc;
reg doResp;
reg [4:0] rocc_cmd_bits_inst_rd_d;
always @ (posedge clock) begin
if (reset) begin
acc <= {xLen{1'b0}};
doResp <= 1'b0;
rocc_cmd_bits_inst_rd_d <= 5'b0;
end
else if (rocc_cmd_valid && rocc_cmd_ready) begin
doResp <= 1;
rocc_cmd_bits_inst_rd_d <= rocc_cmd_bits_inst_rd;
acc <= acc + rocc_cmd_bits_rs1 + rocc_cmd_bits_rs2;
end
else begin
doResp <= 1'b0;
end
end

assign rocc_resp_valid = doResp;
assign rocc_resp_bits_rd = rocc_cmd_bits_inst_rd_d;
assign rocc_resp_bits_data = acc;
```

```
int main(void){
ROCC_INSTRUCTION(3,0);
}
```


I used the chipyard BlackBoxExample configuration, along with the code above, to produce the waveform in the image，my purpose is to write 1024 consecutive 8Byte sizes of data to address `0x60010000` , with successive increments of address.
But on the third write, the rocc_mem_req_ready signal pulled down, and never pulled up.

And I found that this was related to the address that was written, for example I had no problem doing the same to the address `0x80010000` ，The waveform is shown in the figure below：

The difference between these two addresses is that the address `0x60010000` is mapped to the `mmio axi` interface, but the address `0x80010000` is mapped to the `mem axi` interface

On accessing address 0x60010000, the write request made is put into SimpleHellaCacheIF's retransmission queue. inflight indicates how many requests are currently not responding to the resp. A value of 3 indicates that two requests are waiting for the resp(two have a bit of 1). But according to the information I read on the Internet, rocc's memory write operation does not respond, so I don't know if this is a bug.

Because the read operation has response, the read request can be completed normally at 0x60010000

**Please tell us about your environment:** Rocket 1.6

**What is the use case for changing the behavior?**
store operations can be performed continuously

Start with the Chipyard BlackBoxExample configuration and the SimpleHellaCacheIF retransmission queue, then reproduce the waveform for stores to 0x60010000 and 0x80010000. Compare how the MMIO AXI and memory AXI paths handle outstanding write requests. Done means continuous 8-byte stores through the RoCC memory interface no longer leave rocc_mem_req_ready stuck low.

Written by the indexing model from the issue text.