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
It seems that whenever the condition req.valid && !resp.bits.miss is observed within the same cycle, the state will change. However, the TLB requires at least one cycle to return the correct resp.bits.miss, even though the MMIO TLB is blocking. Suppose a TLB request for a specific MMIO is miss, due to the delayed response by one cycle, the MMIO state machine sees miss == false.B. However, the data in the TLB interface is incorrect.
Personally, I wonder if using resp.valid would be better than resp.bits.miss in this case.
The text was updated successfully, but these errors were encountered:
Issue Description:
I have a question about the timing interface for accessing the TLB during MMIO instruction fetches. Although I may not have fully understood the code which is linked in below url. I'm unsure about the behavior of the IFU's (Instruction Fetch Unit) MMIO fetch state machine when checking the TLB's return result.
https://github.com/OpenXiangShan/XiangShan/blob/8fae59bba57fd80fcd1d85aadbf87895b97d167a/src/main/scala/xiangshan/frontend/IFU.scala#L590C1-L590C1
It seems that whenever the condition
req.valid && !resp.bits.miss
is observed within the same cycle, the state will change. However, the TLB requires at least one cycle to return the correctresp.bits.miss
, even though the MMIO TLB is blocking. Suppose a TLB request for a specific MMIO is miss, due to the delayed response by one cycle, the MMIO state machine seesmiss == false.B
. However, the data in the TLB interface is incorrect.Personally, I wonder if using
resp.valid
would be better thanresp.bits.miss
in this case.The text was updated successfully, but these errors were encountered: