Rocket Chip Interrupt Handling

[Hongce Zhang]

Hi, I have a question on how Rocket Chip handles asynchronous interrupts.

From my understanding and the explanation in  https://groups.google.com/a/groups.riscv.org/forum/#!msg/hw-dev/uNE1WL8svXs/vjy1AuN8FAAJ,
an interrupt will cause an illegal instruction inserted. And in the Chisel code, I think it corresponds to using csr.io.interrupt in the id stage to generate id_xcpt/id_cause signal, and these will be carried to the writeback stage and treated similarly as traps/exceptions. Correct?

However,
    1) csr.io.interrupt (from csr to the pipeline) relies on the enabling bits in CSRs
    2) The effect of the enabling bits is on id stage (because csr.io.interrupt is used in id stage)
    3) CSRs are written by CSRRW instructions in write-back stage
    4) I didn't find the forwarding logic to forward the new csr value to CSRFile to determine the csr.io.interrupt in id stage (did I miss them? please help me by pointing it out, thanks! )

So, I suspect whether there is a hazard. Suppose, an instruction turns off the enabling bits, however, before it reaches the WB stage, these new values are not visible to a younger interrupt. So an illegal instruction is injected, and that is *after* the enabling bits has turned off. This confuses me a lot.

Please point out any incorrect reasoning or misunderstanding of the Chisel code. Thank you for your help!

Hongce

[Andrew Waterman]

The hazard is handled with a pipeline flush, so there's no need for forwarding.

> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V HW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hw-dev+un...@groups.riscv.org.
> To post to this group, send email to hw-...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/04a056ed-2363-4120-ad79-7f03d6129056%40groups.riscv.org.

[Hongce Zhang]

Thank you for Andrew's help! I found the logic for flushing the pipe for CSR instructions.

Thank you for your patience!
Hongce

在 2017年4月28日星期五 UTC-4上午11:03:01，Hongce Zhang写道：

[Hongce Zhang]

Hi Andrew,

Sorry to bother you again with this old question!

I understand that CSRRW instruction would cause a pipeline flush. This flush will cause ctrl_killx, ctrl_killd signals to be 1 when the CSRRW instruction is at the memory stage (because of the mem_reg_flush_pipe signal). I have no problem understanding the above behavior. But what I feel is that the flush signal and also ctrl_killx, ctrl_killd, ctrl_killm do not affect ex_reg_xcpt_interrupt, mem_reg_xcpt_interrupt, which means a following interrupt is not flushed, and this would cause the hazard.

I suspect I must have missed something.

Thank you very much for your help!

Best.

Hongce

--

You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/afc920c3-f427-4e87-9747-1c568726b126%40groups.riscv.org.

[Andrew Waterman]

take_pc_wb (hence take_pc) is true when the pipeline is flushed,
causing *_reg_xcpt_interrupt to become false.

>> email to hw-dev+un...@groups.riscv.org.