IRQ discussion
Closed this issue · 6 comments
I have a preliminary branch implementing IRQ in lassen called 'irq'
The features currently are that for both the alu output and the single bit output, you can enable irq along with a comparison value. If at any time during running the comparison is true, the PE will output a 1 on the irq output along with latching that 1 in a register in the PE. The reason for this latch is so that the SOC can easily determine which PE triggered the interrupt.
Open questions for lassen features:
-Should the IRQ be output the same cycle when the interrupt occurs?
-Should we continue output the IRQ till it is cleared by software?
-Should we support multiple comparison operations? (==,!=,<,>,etc)
Let me know your thoughts or any other assumptions I missed.
I think the IRQ should be output in the cycle it is created, since that will allow us to stop the clock before the next cycle (and state change) if we clock it slow enough.
I think that the IRQ should continue to be asserted until explicitly reset, though I think it could be built either way.
Including other comparisons requires a complete adder in the comparison unit. While I don't object to doing this, at this point I think just equality comparison should be enough for this version.
Do we have a signal to reset the IRQ? Do we need to reset individual IRQs or single PEs. It seem too late to make these changes to me.
We would need garnet to add the logic to read and write to these bits which already needs to be done for the other data registers in the PE. @rsetaluri
As Ross said, I think this should be able to be read/written from the configuration bus. It is almost more a configuration state that the hardware can set.
Although one slight caveat is that if garnet is also going to inject an 'en' into each of the registers for stalling purposes, the IRQ register should not be stalled.
We are not using this feature.