Wrong result generated by multiply unit (probably control logic related)

[moimfeld]

Hi @michael-platzer,

Issue

Sometimes the multiply unit does not output the correct result. I think the issue does not lie in the multiplier itself but in the control logic.
Below you can see a screenshot where this issue occurs. All vreg_* and instr_* signals are from the pipeline_wrapper containing the multiply unit, the pipe_* signals are from the multiply unit. The remaining signals are from the vproc_core module.
In the screenshot one can see that at 28'755 ns the correct operands are sent to the multiply unit (pipe_in_op(1|2)), but a few cycles later wrong results (pipe_out_res_o) are passed to the pipeline module (and these wrong results are then aggregated and written to the register file). It is important to note that the wrong results passed to the pipeline module are exactly the same as the last result of the previous instruction. So it might be that the control logic somehow keeps some valid signal asserted for too long.

It is important to note that this issue only occurred when I enabled "commit delay", "result delay" and "illegal instructions" in the UVM environment. So it could be that the issue is related to some kind of delay on an xif channel.

This is an exemplary UVM_WARNING generated for the issue above.

# UVM_WARNING cvxif_scoreboard.svh(412) @ 28930: uvm_test_top.env.scoreboard [CVXIF_SCOREBOARD] Instr "vmulhsu.vx v15, v22, a1 m1, tu, mu" with id = 5 in Prog "vmulhsu_vx" failed: 
# at      28930 ns: 
# State Difference
# ref.vproc_register[15]: 277b56dcb12897d6d2cc21def7027354ffd6004e0046001c0000000000000000, dut.vproc_reg[15]: 277b56dcb12897d6d2cc21def7027354fe240235075ef99dfe13ff6ffdfdfdec

How to reproduce

Run the following command:

make UVM_TESTNAME=cvxif_test_direct_issue_101 SEED=1

Please note that SEED=1.

[moimfeld]

From further observation I found that this issue only arises when "commit delay" is enabled.
Usually what causes the result to be wrong is that either the value on the pipe_out_res_o stays the same for multiple handshakes with the pipeline (even though it should change). Or that one result is never passed to the pipeline, i.e. its lost in the multiplier.