`instr_notspec_d` signal gets updated even for illegal instructions (causing infinite stall)
moimfeld opened this issue · comments
Issue
When offloading illegal instructions to Vicuna, the coprocessor sets the instr_notspec_d[{illegal_instr_id}] bit to 1 even though the instruction was not accepted (I think this is the source problem). This bit is never reset to 0 because there is never a corresponding instr_complete_valid signal. So the next instruction with the same id as the illegal instruction will cause an infinite stall, because the issue handshake will never be completed (issue handshake depends on the instr_notspec_q signal via the issue_id_used signal).
In the screenshot below you can see:
- at 1115 ns, illegal instruction issue transaction (
accept= 0 andid= 3) - at 1125 ns,
instr_notspec_q[3]is set to 1 (source of the issue I think) - at 1265 ns, start of infinite stall, because
instr_notspec_q[3]is never reset
Note: All signals are from the cvxif or the vproc_core module.
How to reproduce
To reproduce this issue run the cvxif_test_direct_issue_88 test in the UVM environment.
Hi @moimfeld,
the instr_notspec_[q|d] bits indicate whether an instruction is speculative or not. If an instruction is speculative (or the ID is invalid), then the corresponding bit is 0, and once the instruction is either committed or killed (thus no longer speculative), then the corresponding bit is set. Therefore, these bits are not set when the instruction is offloaded, but rather when it is committed (or killed) by a commit transaction. At 1115 ns, there is a commit transaction with ID 3 simultaneously with the associated issue transaction, which causes the bit to be set.
I just realized that a note has been added to the XIF spec stating that a CPU shall commit instructions even if they have been rejected. This is not yet supported by Vicuna.
As a temporary workaround, could you inhibit commit transactions for rejected instructions in your UVM environment? That should avoid this issue while I work on a solution that complies with the updated XIF spec.
Hi @michael-platzer,
Thanks for the answer! I will locally deactivate the commit transactions for illegal instructions until this is fixed.
I think, an easy way to fix this might be to add another signal pair that tracks pending commit transactions (something like: instr_await_commit_[q|d]) and use this to mask the update of the instr_notspec_[q|d] signal.
@moimfeld Thanks!
I would like to avoid adding additional state, so I was thinking of combining the instr_not_spec_[q|d] signal with instr_killed_[q|d] into a 2-bit enum for each instruction ID, with states INVALID, SPECULATIVE, COMMITTED, and KILLED.
I actually like your solution better as well.
Hi @moimfeld,
this issue should be fixed now. I have merged the instr_not_spec_[q|d] and instr_killed_[q|d] signals into a instr_state_[q|d] signal that allows now to differentiate between invalid and speculative instructions. In 3d73e6c the old signals have been replaced with the new instruction state signals (but still applies XIF commit transactions to invalid IDs) and commit 886195c ignores XIF commit transactions with invalid IDs.
It appears that your UVM environment depends on the presence of the old signals within vproc_core, thus I have not verified whether the issue is actually gone, but it since the commit transaction is now ignored if the instruction is invalid, I believe that it should be fixed. Please let me know if you encounter any issues with these changes.
Thanks a lot! I will check it in the afternoon.
Your commits do fix the issue.
And you were right that the UVM environment referenced the signals that were renamed/changed. Tomorrow, I will push a commit to the UVM environment repository that will make it compatible with the newest version of Vicuna.
Thanks again 😄
I will close this issue now.