problem of out of order retire

[AD738560581]

@mp-17 @suehtamacv Hello,
thank you very much for your open source project, which has brought great help to our team. I see that you have recently updated many small flaws in the past, such as vstart support, tlb support, and support for seg, compress, vrgather and other instructions.However, we have also discovered an ill-considered point. Because ara adopts the strategy of sequential issue and out-of-order retirement, RAR has also become a potential data risk. For example, vdiv v0, v1, v2; vadd v3, v1, v2; vsub v1, v5, v6 code segment, vadd and vdiv are not risky, but it is RAR, vsub, vdiv and vadd are all WAR. However, when vadd is issued, the read_list in main_sequencer will be updated. At this time, vsub builds an adventure with vadd. When vadd retires, the vdiv may not have retired. At this time, vsub can start writing back. If vset is m8, at this time vdiv will read the result written back of vsub.

Therefore, we simply adopt a sequential retirement structure, and use a reorder structure in main_sequencer to ensure that retirement in the scoreboard of main_sequencer is sequential, and the writeback order is not modified, thereby extending the blocking time of the hazard. As in the above example, vadd needs to wait for vdiv to retire before vadd can retire from the scoreboard.

However, this is not necessarily the best way to repair it. If you have completed this part of the repair, can you share it?

[mp-17]

Hi @AD738560581, thanks for reporting this! Very interesting bug. We have not fixed it yet.

From a quick look, I have two ideas on how to fix it:

1. Probably similar to what you have already done: extend the hazard engine of the main sequencer to deal with RARs. In practice, the hazard_vXX bits of every pe_req need to be updated from the read table, too. This will serialize the operand fetch of instructions that read from the same register.
   This is the least intrusive fix in terms of hardware complexity but it's not ideal and can potentially lead to cycle-performance slow downs on certain applications.

2. Slightly modify the current read table of the main sequencer to keep track of all the instructions reading from each register. Right now, the read table only records the id of the last instruction reading from each vector register. This should be modified. Instead of the id of the last reading instruction, we can record a bit mask (8-bit long per vector register, instead of the 3-bit id per vector register) with 1s at the indices at which a vector instruction is reading from that register. This should also ease the hazard tracking and transcription in the current pe_req. From a quick look, I think this should then work "out of the box" in the lanes' operand requesters. This solution should not lead to performance degradation, but can have a possibly higher impact on the max frequency. However, I expect it to be small or negligible.

I am not in the PULP project anymore and can't check the hardware impact of the modification, but probably @Navaneeth-KunhiPurayil can or has additional remarks on this.

[AD738560581]

@mp-17 Thank you very much for your reply, it is of great help to me. I will revise ARA based on your opinions. If there is better progress, I will synchronize it with you.