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

Placeholder David Mallasén Quintana
2023-09-07T15:17:48Z

## Redundant mem_result when using CORE-V-XIF

### Component
Issues in the RTL

### Steps to Reproduce
Git hash: v0.8.0 974ca469f3a7598e99b5c6eb9d6a4b355fe8c9da

Hello,

I'm using CV32E40X inside [X-HEEP](https://github.com/esl-epfl/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:
![Screenshot at 2023-03-08 15-53-17](https://user-images.githubusercontent.com/15904722/223765309-9ab57cb0-9938-4f72-960a-d9ff2d153aae.png)

I atttach a screenshot of the waveform of the XIF signals:
![Screenshot at 2023-03-08 15-50-11](https://user-images.githubusercontent.com/15904722/223766058-19385c7a-1457-401a-9574-ff612400c22d.png)

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](https://github.com/openhwgroup/cv32e40x/files/10922588/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.
![Screenshot at 2023-03-08 15-53-59](https://user-images.githubusercontent.com/15904722/223768748-7380c21c-2138-4a08-8743-826816f78afe.png)

Thanks!
David