XIF issue interface uses same instruction ID for two consecutive offloaded instructions

Created by: michael-platzer

Component: Component:RTL Git Hash: 9c1d3db4

The XIF issue interface sometimes uses the same instruction ID for two consecutive offloaded instruction, although the first instruction has not retired. This happens when an instruction is accepted by the coprocessor but the pipeline is currently stalled and hence the offloaded instruction remains in the ID stage despite having been accepted. In such a situation the xif_accepted_q register in the ID stage is set, which de-asserts the issue_valid signal of the XIF issue interface (intentionally so, since the instruction has already been accepted).

However, the issue_valid signal is also used by the IF stage to decide whether a new instruction ID needs to be generated. Hence, if the ID stage is stalled while an offloaded instruction has already been accepted, then the IF stage does not increment the instruction ID. This leads to the same ID being assigned to the next instruction.

The problem is shown in the waveforms below. Two instruction with IDs 0 and 1 are offloaded normally, as shown by the signals issue_valid and issue_ready (with the associated ID shown by issue_id). The instruction ID in the IF stage (signal xif_id) is incremented for each of these two instructions. Next, an instruction with ID 2 is offloaded and accepted by the coprocessor. However, the ID stage is stalled and thus xif_accepted_q is set to indicate that the instruction in the ID stage has already been accepted. While xif_id briefly switches to 3 while the coprocessor accepts instruction 2, it then goes back to 2 once issue_valid is no longer asserted. Consequently, when the next instruction enters the ID stage, the associated instruction ID is still 2 and the XIF interface re-uses the same ID, although the previous instruction has not retired.