Mips32 strange behavior

[massas]

Hello,

I have encoutered some problems with the mips32 iss, I have the following behavior on a miss instruction meanwhile an irq is raised :

t-0 : The mips32 issues an address to the cache wrapper which miss in the tag. The cache wrapper sets the iss_t::InstructionResponse.valid to false (stall the processor).

t-1 : The cache wrapper send a read request to the memory and wait for the response. Meanwhile, the mips32 receive at each cycle a negative response for InstructionResponse.valid.

t-2 : The processor receives an irq, and CHANGES the output adress (next_pc).

t-3 The cache receives the response from the memory and updates the TAG with the NEW address (which is incorrect), because it did not expect that the processor could change the output address beign stalled.

My question is the following : Is a correct behavior for the mips32 to take into account an irq (or other event) meanwhile it is stall ?

I know that on other processors a stall signal freezes the state of the processor, so it will mantain the same output address until it "hits" in the cache.

Thank you for your highlights to this question.

[Nicolas Pouillon]

First, for t-1, the icache and dcache both have their own "valid" signal, that means the ifetch may continue while the dcache is stalling, or the other way around.

Now for the real question here, about the fact the CPU changes its mind about the current request even if the cache did not answer the last one, this is not invalid per se (the answer is "the response is invalid", not "i want you to stop"). Moreover, we had some discussions about this point internally at Lip6, and found out that allowing the CPU to change its mind could speed things up a little at the expense of adding a register in the cache to store the instruction request address, which we already have anyway.

So, yes, Mips32 changes request when an IRQ comes, and yes, it is intended.