Currently, the way the lsu replay works is that when a load is issued to the lsu pipe but it is not ready because of a cache miss, it is put in the replay queue with an automatic delay of 3 cycles before it can be tried again.
However, the above functionality is perhaps not working as intended and the problem is as follows:
(this is what happens chronologically, (see the attached output trace load_to_use_lsu_info.txt)):
- cycle 50: Load missed cache in cycle 50 and it cannot complete
- It is put in the replay queue (using updateInstReplayReady_) with a 3 cycle delay, it should be tried/played again in cycle 53
- cycle 51: However, this function (updateInstReplayReady_) is called again in cycle 51 to put the load in the replay queue for 3 cycles.
- This time in cycle 51, it is able to schedule the load to be replayed after 3 cycles successfully and it replays again at cycle 54.
- cycle 54: The same load is still not able to complete and (updateInstReplayReady_) is called to replay it in 3 cycles.
- cycle 55: Again, the above replay called in cycle 54 is not "respected" and it (updateInstReplayReady_) is called again to replay the load in 3 cycles.
- cycle 58: Load is tried again, replay for 3 cycles is called but not respected.
- cycle 59: replay for 3 cycles is called and respected
- cycle 62: ...same pattern.....
It seems that this is not intended because we are taking an additional cycle every-time we replay this load and the replay is set to 3 cycles (not 4).
If the intention is to replay after 4 cycles, we should just change the replay parameter to 4 instead of what is happening above.
Unless this is somehow intentional, this seems like a bug.
This uses the load_to_use trace already in the repo.
load_to_use_lsu_info.txt
load_to_use.txt
Currently, the way the lsu replay works is that when a load is issued to the lsu pipe but it is not ready because of a cache miss, it is put in the replay queue with an automatic delay of 3 cycles before it can be tried again.
However, the above functionality is perhaps not working as intended and the problem is as follows:
(this is what happens chronologically, (see the attached output trace load_to_use_lsu_info.txt)):
It seems that this is not intended because we are taking an additional cycle every-time we replay this load and the replay is set to 3 cycles (not 4).
If the intention is to replay after 4 cycles, we should just change the replay parameter to 4 instead of what is happening above.
Unless this is somehow intentional, this seems like a bug.
This uses the load_to_use trace already in the repo.
load_to_use_lsu_info.txt
load_to_use.txt