[XIF] Redundant mem_result when using CORE-V-XIF
Created by: davidmallasen
Redundant mem_result when using CORE-V-XIF
Component
Issues in the RTL
Steps to Reproduce
Git hash: v0.8.0 974ca469
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 1Where the last 3 ones should be 0 1 1.
I also attach a VCD dump of this execution.
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