Why interrupts are entering the datapath at decode stage?

[omerguzelelectronicguy]

The explanation below is taken from the https://docs.boom-core.org/en/latest/sections/reorder-buffer.html?highlight=interrupt documentation.

all other exceptions and interrupts can be handled before the instruction is dispatched to the ROB

I understand the interrupts are taken at the decode stage. I assume it is placed at ROB and fires when it comes to the head of ROB (I assume in this way because CSRs are not renamed so it cannot be executed speculatively). In this way, an interrupt might fire too late according to the size of ROB and the fullness of ROB. Isn't it a problem?

I asked this question also in Stackoverflow. It points to a question (saw my question as a duplicate). The accepted answer says intel is flushing the rob when an interrupt occurs. Is it same in BOOM?

[ccelio]

Isn't it a problem?

I think this depends on what you define as "a problem". I suspect that the service level requirements of "timeliness" is a platform-level agreement, not an ISA-level agreement. Obviously a real-time platform would be much more strict on setting a bounds on how quickly an interrupt would be taken. BOOM does the easy thing and waits for the interrupt to hit the ROB head, instead of being more aggressive (and wasteful) by flushing the ROB so the interrupt can be re-inserted as the new ROB head.

So what Intel does, if the claim is true, is handle the interrupt much sooner, and in a manner that one can more easily put a bound on the timeliness. I also wouldn't be surprised if other complications -- perhaps sleep states, long micro-code sequences, or machine checks -- might be interfering with an interrupt making it to the ROB head, such that it's easier to just flush the ROB and move the interrupt to the top, and not ponder the enormous validation space that might get in the way of an interrupt being handled.

Feel free to submit a pull request. :D