[XIF] Redundant mem_result when using CORE-V-XIF

[davidmallasen]

Redundant mem_result when using CORE-V-XIF

Component

Issues in the RTL

Steps to Reproduce

Git hash: v0.8.0 974ca46

Hello,

I'm using CV32E40X inside X-HEEP together with a coprocessor that interacts with XIF. Through the XIF I'm receiving a redundant mem result from the CV32E40X that I believe should not be there. I'm not sure if it's a problem from my side or from the CV32E40X, but checking the waveforms I see everything correct from the coprocessor side (as I understand it).

I'm running the following snippet of code, where plw can be read as a normal lw but to an external register file in the coprocessor, and peq are equal operations between registers of this external RF that should write back a 0 or 1 to the GPRF of CV32E40X:

I atttach a screenshot of the waveform of the XIF signals:

The first 3 issue_ready - issue_valid handshake signals are for the 3 plw, and the next 3 are for the 3 peq. They are all signaled a commit_kill = 0, so the coprocessor initiates memory retrievals of the plw instructions with the 3 mem_valid - mem_ready handshakes. CV32E40X replies correctly through the mem_result interface, but after a while (right after the 3 peq instructions are executed and signaled via the result interface. There is an extra mem_result_valid where the yellow cursor is (identical to the last one) that should not be there, as there is no 4th mem request.

The output of the above program is:

 PEQ test FAIL - Values: 7f939d17 7f6ec2bf 806e6c7b 1 1 1

Where the last 3 ones should be 0 1 1.

I also attach a VCD dump of this execution.

waveform.vcd.zip

If it helps, this only happens with operations that end up writing back to the GPRF. Other snippets of code such as the following, work correctly.

Thanks!
David

[davideschiavone]

thx @davidmallasen , pinging @silabs-oysteink and @Silabs-ArjanB

[Silabs-ArjanB]

Hello @davidmallasen Thank you very much for filing this issue. It looks like an RTL bug indeed. Unfortuantely the vcd file does not seem to actually contain data for the cv32e40x_core_i scope and below:

Is it possible for you to generate a new vcd tracing all signals below that scope?

Best regards,
Arjan

[davidmallasen]

Hello @Silabs-ArjanB
I'm sorry, but I'm able to see all those signals in GTKWave. Maybe the issue is that I only included the important time interval?

[Silabs-ArjanB]

Using GTKWave I can now see the waves. Thanks for mentioning that tool. Is it possible to see if_xif.cpu_mem_result xif_mem_result_if as well in the load store unit or is there a limitation on viewing System Verilog interfaces?

[davidmallasen]

That may be a limitation on the SV interfaces, I can't see it either

[Silabs-ArjanB]

Hi @davidmallasen I see what is going wrong in the RTL. Basically the WB stage is not applying back pressure to the load store unit if the WB stage is waiting for the result of an offloaded XIF instruction. The issue is similar to (or maybe even the same as) #653.

Will discuss internally when we can fix this.

[davidmallasen]

Great, thanks @Silabs-ArjanB !

[Silabs-ArjanB]

[davideschiavone]

hi @Silabs-ArjanB - it seems you commented without text :D

[Silabs-ArjanB]

Yes, just a screenshot of the relevant signals as a reminder to myself

[Silabs-ArjanB]

@davidmallasen Are you blocked by this?

[davidmallasen]

Yes, it's not allowing me to continue with my work

[Silabs-ArjanB]

Note that #825 was closed but its proposed fix has not been merged yet

[davidmallasen]

Correct, the closing of the PR was an unintended side-effect, sorry about that @Silabs-ArjanB