APU keeps re-despatching the same instruction while previous instruction is not completed

[LucaRufer]

If an APU-offloaded instruction finishes before the previous instruction, it is re-dispatched until the previous instruction is completed. For example, consider the following core snippet:

flw	fa1, 0(a0)
fmv.w.x	fa2,zero

If the load instruction takes longer to complete than the move instruction, the fp move instruction is dispatched again as soon as it finished until the load completes, leading to unnecessary offload requests. The result of the APU instruction is written back into the register file every time it completes. The source for this is that the ID stage keeps the apu_en_ex signal high until after the previous instruction is completed. The APU dispatcher interprets this as a new request and attempts to offload it again.

I assume the intended bahavior should be that the result of the APU instruction is stored in apu_rvalid_q / apu_result_q after completing the first time until it can be written back into the register file and the apu_valid is de-asserted, as it is currently done for other stall sources.

[MikeOpenHWGroup]

Thanks for this Issue @LucaRufer. Just to clarify, are you seeing incorrect behaviour or unnecessary offload requests that (eventually) lead to correct behaviour?

[LucaRufer]

So far, I have not seen incorrect behaviour yet. As the result of the APU instruction is written back into the register file (depending on the latency of the APU instruction) before the load completes, I tested combinations like

flw	fa1,0(a0)
fadd.s	ft0,ft0,ft0

with a non-zero value in ft0. While the register file gets updated with the APU instruction first and the load instruction later, the pipeline stages behave correctly and do not forward the updated operand ft0, so the APU executes repeatedly with the same operands. So it seems it only causes unnecessary offload requests without incorrect behaviour.

[MikeOpenHWGroup]

So it seems it only causes unnecessary offload requests without incorrect behaviour.

Well, that's a relief. Nevertheless, this is clearly not desirable for power dissipation. We'll look into it. In the meantime, if you would like to submit a fix, we would be happy to review your PR.

[pascalgouedo]

Hi,

This a known problem. It was possible to correct other power dissipation bugs but this one was quite tricky.
I tried to correct it but there was bad side-effects (can't remember exactly which ones).
apu_rvalid_q / apu_result_q was only added later on to correct bugs for multi-cycles FPU instructions (LAT greater than 1) and when specific pipeline conditions occur.
Maybe it could have been used to try to correct this specific problem, good point.

@MikeOpenHWGroup Be careful that changing anything from CV32E40P v1.8.3 release would invalidate everything which has done on RISC-V ISA formal verification side.

Regards,
Pascal.