RoCC: io.mem.req.ready stuck

[ARF1939261764]

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