Elaborate on use-case for changing issue_req.id

[christian-herber-nxp]

From the documentation, it is not clear what the benefit of changing id is over deasserting valid.

[jklockars]

Isn't the idea there that either

• the instruction that earlier was valid now is not or
• there is now a new instruction (and thus, implicitly, the old one is not valid)

The coprocessor could still accept the previous instruction (by asserting ready etc) a moment before the clock edge where the main pipeline deasserts ready (or changes ID), right? This can be seen in the next cycle by the main pipeline, which would then be responsible for killing the instruction later. Right?

Unless I am missing something, the documentation does not say that issue_valid is a registered (clocked) signal. Is it supposed to be allowed to combinatorially deassert it?

[christian-herber-nxp]

The coprocessor could still accept the previous instruction (by asserting ready etc) a moment before the clock edge where the main pipeline deasserts ready (or changes ID), right? This can be seen in the next cycle by the main pipeline, which would then be responsible for killing the instruction later. Right?

I guess thats the intention. You would avoid the issue if you would deassert valid before issueing a different instruction.

[christian-herber-nxp]

@Silabs-ArjanB : Can you reproduce in which scenario changing the id is better than deasserting valid? In the scenarios I can think off, you will deassert valid anyway because you need to wait for the next instruction to be fetched, be it after a mispredicted branch or a trap.

[Silabs-ArjanB]

@christian-herber-nxp The XIF specification defines a point-to-point link. That does however not mean it does not take into account interconnect based considerations. In this case the requirement is not important for the processor itself. If a processor decides to retract a transaction it can simply lower the request signal for a cycle. However, if you share a coprocessor between two processors then it would be nice (performance and implementation wise) if as soon as one processor retracts its request that the other processor can have its request forwarded to the coprocessor. From the coprocessor point of view this would appear as a changed ID while the request remained high.

As said above: XIF is still a point-to-point protocol but there are requirements like this that enable easier building of an interconnect matrix.

[christian-herber-nxp]

@christian-herber-nxp The XIF specification defines a point-to-point link. That does however not mean it does not take into account interconnect based considerations. In this case the requirement is not important for the processor itself. If a processor decides to retract a transaction it can simply lower the request signal for a cycle. However, if you share a coprocessor between two processors then it would be nice (performance and implementation wise) if as soon as one processor retracts its request that the other processor can have its request forwarded to the coprocessor. From the coprocessor point of view this would appear as a changed ID while the request remained high.

As said above: XIF is still a point-to-point protocol but there are requirements like this that enable easier building of an interconnect matrix.

If as you state this is for multi-hart use cases only, then this change https://github.com/openhwgroup/core-v-xif/pull/105 should make it rather explicit. Then if only one hart is there, the coprocessor does not have to expect a change of ID on a valid transaction.