Fixed XIF Control Signals for Sticky Accept/Reject

[Aidan-McNay]

A quick fix I noticed when using the core; a lot of my issue responses weren't able to write back due to the lack of tracking XIF control signals when the pipeline was stalling (a.k.a. "sticky accepts"). This fix keeps track of these signals on sticky accepts to ensure that they are correctly forwarded. @Silabs-ArjanB @silabs-oysteink Let me know what you think!

(I tried following the link in the Contributing guidelines to OpenHW Work Flow document, but it seemed broken - let me know if there's anything I need to fix!)

[Silabs-ArjanB]

Hi @Aidan-McNay Thank you very much for your contribution and apologies for our slow response! Could you please in words describe a scenario that would be fixed by this PR? (E.g. if a ...instruction is in the WB stage that has ... signal set to ... and there is a ... instruction in EX that ... then ...). Currently we are prioritizing non-XIF related work and I do not know yet when we will have time to properly address all the XIF related issues. (We plan to make significant changes to the XIF related architectures and we would therefore want to address all related issues at the same time once we start that.)

[Aidan-McNay]

Hi @Silabs-ArjanB - no worries! I had changes to two files:

• Changes to cv32e40x_id_stage.sv were meant to make sure that we properly retained the flags from an XIF response if it was issued when the EX stage isn't ready. With the way the file currently was, we are able to issue to XIF even when were stalling (and keep track of doing so with xif_accepted_q and xif_rejected_q. However, when doing so, we don't keep track of any of the other response fields, such as we, exception, dualwrite, and loadstore. This means that if the coprocessor changes these flags after giving the issue response, the changed (incorrect) flags will be passed down the pipeline. My solution registers these flags so that we pass on the flags associated with the coprocessor issue response
• Changes to cv32e40x_wb_stage.sv were because of a similar issue; if WB was stalling (i.e. wb_ready_o was low), the XIF result would be taken, but not kept track of, and essentially dumped. While we could register the results here (similar to before), I found it easier to just AND the XIF ready signal (xif_result_if.result_ready) with wb_ready_o to make sure we only take XIF results when we're ready. Maybe we want to modify this to be a similar solution to ID instead? Looking for feedback

Happy to draw out waveforms as well, if it's helpful, as well as if there's better issues to tackle currently, happy to help there too :)