Store-to-load forwarding when cache miss in Lsu2 Plugin

[atkarim]

Hi @Dolu1990,

I'm currently studying the Lsu2 plugin, and I may have an optimisation to suggest.

When a load instruction is processed in sharedPip, we check whether an older store instruction points to the same address in the checkSqMask and checkSqArbi stages.
If we detect an older store instruction with the same address, we have OLDER_STORE_HIT = True, and if this store is not waiting for address translation, we have OLDER_STORE_BYPASS_SUCCESS = True.

So, if this is the case, we're performing store-to-load forwarding, the data from the store is transmitted to the load, and written to the register.

Finally, if I've understood correctly, at the ctrl stage, we should enter the SUCCESS state, to indicate that the load instruction has been executed successfully. This is the case when the cache response is a cache hit.

However when the cache response in cacheRsp stage is a cache miss, we enter LOAD_MISS state in ctrl stage as rsp.redo = True.

NaxRiscv/src/main/scala/naxriscv/lsu2/Lsu2Plugin.scala

Line 1160 in d7213a3

}.elsewhen(IS_LOAD && rsp.redo) {

We will have to wait for the cache refill before entering the SUCCESS state, even if we already have the data we need to load.

My suggestion is to modify the above line in the Lsu2 plugin to avoid the LOAD_MISS state and enter the SUCCESS state directly when there is a store-to-load forwarding.

}.elsewhen(IS_LOAD && rsp.redo && !OLDER_STORE_BYPASS_SUCCESS) {

By doing this :

• the cache will still be refilled, which is a good thing if subsequent load instructions point to that cache line.
• the store-to-load forwarding is optimised and saves clock cycles.

I hope I've understood your plugin correctly, and that I haven't forgotten something that would make my suggestion invalid.

Thank you in advance for your feedback

[Dolu1990]

Hi,

Congratulation for being able to read the LSU2 monolite :)

So, yes you are right i think, when store to load bypass happen, we don't need a cache hit, but there is one very corner case thing :

• NaxRiscv doesn't check store access being denied by the memory interconnect
• So, if you assume a load is OK because it had a store bypass on cache miss, but the address accessed is effectively not memory mapped (denied by memory interconnect), then you will not produce a trap on the memory load either.

Very corner case.

[atkarim]

Hi,

Thanks for your response.

I don't know if I can understand all of LSU2, but I'm trying. It's such a complex thing in an out-of-order core, congratulations on developing it.

Yes, you're right, I hadn't thought about that scenario, which is very interesting, you really have to think about everything.
This should require you to carry out a considerable amount of verification work during the development of your core.

[Dolu1990]

Hi,

This should require you to carry out a considerable amount of verification work during the development of your core.

Debugging things is kind of easy, as long as the CPU behaviour is cross checked against a reference RISC-V model to catch the issue as soon as it happens. The main issue i git is to get "interresting" stimulus. https://github.com/chipsalliance/riscv-dv is unfortunatly System verilog, so not realy open-source dev friendly.

Currently i'm mostly using "booting linux" as a "indepth" stimulus generator, which isn't realy great XD