Inconsistency between issue and result interface

[christian-herber-nxp]

Issue response uses writeback and dualwrite signals to communicate to the CPU that it will writeback to one or two registers. There is no requirement that states dualwrite may not be high when writeback is low. Result uses a we signal, which is two bits wide for register pairs. The bit corresponding to the odd register may only be asserted if the one for the even is asserted.

The issue solution is a bit cleaner when it gets to how this is supposed to be used, if you would add the requirement that either dualwrite shall be driven low when writeback is low, or if you state that the CPU should ignore dualwrite signal if writeback is 0.

The we solution has the advantage of being parameterized, i.e. you do not have the dualwrite signal in the interface when not supporting pairs. Thus, I would be inclined to change the writeback signal to the type of we.

In more general terms, do we actually need those signals on the result interface? The CPU knows which registers this instruction is writing back to based of the issue response. Maybe this can be removed alltogether.

[christian-herber-nxp]

@Silabs-ArjanB : I just looked into the cv32e40x on that matter, and found this comment:

// TODO: How to handle conflicting values of ex_wb_pipe_i.rf_we (based on xif_issue_if.issue_resp.writeback in ID) and xif_result_if.result.we?

So it seems this issue is unresolved. Maybe removing result.we would solve this