Signal stability issue on result interface about vicuna HOT 4 CLOSED

Hi @moimfeld,

thanks for pointing this out! I did not realize that the specification requires the result signals to be kept stable until the CPU is ready to accept the result. So far, Vicuna has dynamically selected the result with the highest priority from four different sources (empty, LSU, CSR, or XREG writeback results). If a result with a higher priority becomes available, it would take precedence over the other results (e.g., a LSU result becoming available while Vicuna is trying to return an empty result).

I have made some changes in f10d789 that prevent changing the result source during an ongoing result transaction. That should mostly fix this issue, although with following exception: signals that are not valid may change. For instance, if the we signal of the XIF result packet is 0, then the signals data and rd are don't cares since writeback is inhibited anyways. The same applies to exccode if exc is 0. I am still thinking of a way to address this. However, I am wondering whether an invalid signal (the value of which could be X) does actually need to remain stable. I will open an issue in the XIF repo to discuss this topic.

from vicuna.

Hi @michael-platzer

Thank you very much for the fix! 😄

Still, I will keep the issue open until the discussion in the cvxif issue you opened comes to a conclusion.

from vicuna.

Hi @moimfeld, with commit 40a11a2 this should now be definitely resolved. XIF result signals should now hopefully remain stable during a transaction :)

from vicuna.

Hi @michael-platzer,

I will close this issue then. Thanks again!

from vicuna.