You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Type of issue: bug report
Impact: rocc memory interface
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 themmio axi
interface, but the address0x80010000
is mapped to themem axi
interfaceOn 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
The text was updated successfully, but these errors were encountered: