Question about s2_mq_nack Signal of LoadPipe.scala

[diantaowang]

Before start

• I have read the RISC-V ISA Manual and this is not a RISC-V ISA question. 我已经阅读过 RISC-V 指令集手册，这不是一个指令集相关的问题。
• I have read the XiangShan Documents. 我已经阅读过香山文档。
• I have searched the previous issues and did not find anything relevant. 我已经搜索过之前的 issue，并没有找到相关的。
• I have searched the previous discussions and did not find anything relevant. 我已经搜索过之前的 discussions，并没有找到相关的。
• I have reviewed the commit messages from the relevant commit history. 我已经浏览过相关的提交历史和提交信息。

Describe the question

When I read the source code and try to figure out the reasons which make load to replay, I encountered some problems.

version: master, 6639e9a (2024-11-21)

The following situations will cause the load instruction to be quickly reissued in the S3 stage:

• DCache bank conflict
• way predict error
• mshr is full when cahce miss
• write back queue reject the miss request
• miss queue cancel the miss request

But the logic of generating s2_mq_nack signal is puzzling. The original code snippet as follows:

io.lsu.s2_mq_nack       := (resp.bits.miss && (!s2_miss_req_fire || s2_nack_no_mshr || io.mq_enq_cancel || io.wbq_block_miss_req))

Why we need s2_miss_req_fire? It's confusing that s2_valid==0 will lead s2_miss_req_fire==0 and s2_mq_nack==1. It seems like that s2_valid is directly related to s2_mq_nack. This may or may not cause errors, due to the complex prioritization logic that follows. For example, the tlb miss will lead the s2_valid equals 0, but C_TM has higher priority than C_DR.

I would like to know whether s2_miss_req_fire is redundant. If not, please explain why, and if so, please modify the code for better readability.

Thanks!!!

[Anzooooo]

Thank you for your interest in the OpenXiangShan.
It does look like this is a redundant signal, which may have been inherited from the code of a previous version. We will discuss again whether more redundant signals can be removed, and we will get back to you if there is any new development.
Thank you again.