[XIF] The controller FSM's XIF commit tracking signals sometimes fail to be reset

[michael-platzer]

When the XIF interface is enabled, the controller FSM uses the signals commit_valid_q and commit_kill_q to track whether an XIF instruction already received its commit transaction. These signals must be reset every time a new XIF instruction enters the EX stage, otherwise the commit transaction never happens causing a deadlock.

The current implementation sometimes fails to reset these signals when a new instruction enters the EX stage.

[Silabs-ArjanB]

@michael-platzer Could you give an example where you get a deadlock.

Currently these flops get reset when something leaves the EX stage (or EX gets killed), which is similar (but not the same) to something new entering EX. I don't easily see an example where the current code fails.

The current code has exactly the same structure (on purpose) as the following XIF related code in ID.

  always_ff @(posedge clk, negedge rst_n) begin : ID_XIF_STATE_REGISTERS
    if (rst_n == 1'b0) begin
      xif_accepted_q <= 1'b0;
      xif_rejected_q <= 1'b0;
    end else begin
      if ( (id_valid_o && ex_ready_i) || ctrl_fsm_i.kill_id ) begin
        xif_accepted_q <= 1'b0;
        xif_rejected_q <= 1'b0;
      end else begin
        xif_accepted_q <= xif_insn_accept;
        xif_rejected_q <= xif_insn_reject;
      end
    end
  end

So I wonder if we would have the same issue in ID as well.