Concerning the IDLE instruction

[tnt]

Ok, good to have the info.
But even then.

- Aren't the instruction fetched 8 bytes at a time ? so aligning could guarantee execution one after the other.
- Then even if both are executed at E1, the pipelining could still delay the interrupt (because if the interrupt is triggered right after GIE enabled it during E1, does it flush the pipeline and prevent the IDLE to execute in E1 or does it continue to execute what's already in the pipeline and just fetch the next instructions from the interrupt handler).

There are so many things I can think of that can make this race happen or not that the only way I can think of to be sure would be to simulate the HDL ...

[EggBaconAndSpam]

the two instructions being fetched at the same time does not guarantee both to execute.
an interrupt after fetching the first would cause a flushing of the pipeline, probably not including the issuing of a second instruction.

but you are correct, no way to be sure without access to the hdl sources.

[tnt]

My point was that :
- Maybe it's just _impossible_ to get an interrupt between. Maybe the bit of the status register and the interrupt input go through a flipflop somewhere in between the actual bit storing the 'interrupt enable' and when it's effectively used to trigger an interrupt and it's just impossible to get an interrupt on the cycle right after it's executed. (and this actually seem pretty likely just for timing reason)
- Or maybe the interrupt doesn't cause a pipeline flush and just causes the _next_ fetch to fetch from the ISR address (and so whatever instruction were in the pipeline will get executed)

[EggBaconAndSpam]

yep, mixed that up, no pipeline flush.
the whole "Maybe it's just _impossible_ to get an interrupt between" doesn't seem likely to me, although it certainly is possible.
basically if reading a 64-bit input buffer were to guarantee the execution of the read instructions (unless a branch occurs, ofc), then we would be safe.
would be a strange implementation though...

the whole flip-flop thing doesn't make much sense to me, as that would only add latency. note that the writes to STATUS are carried out only in E1, no further synchronisation around that takes place.

[notzed]

[aolofsson]

The global interrupt enable is the output of the status register, which gets written at the end of E1 of the GIE instruction.
There is another register stage delay between the logical interrupt signal below and the "ic_irq" interrupt signal that goes to CPU pipeline and is responsible for saving the PC in the iret. If we align the GIE and IDLE instructions on a 64 bit boundary in the code as a workaround, then we know that they will enter the pipeline together on consecutive cycles guaranteeing that the interrupt cannot sneak between the GIE and IDLE instructions (really on the GIE instruction). I agree it would have been better to enable interrupts automatically with the IDLE instruction.. but sometimes you get lucky

Here's the key RTL code snippet..

assign ic_irq_select[IRQW-1:0]= ic_masked_ilat[IRQW-1:0] & //only if the ILAT bit is not masked by IMASK
~ic_ilat_priority_en_n[IRQW-1:0] & //only if there is no masked ilat bit <current
~ic_ipend_priority_en_n[IRQW-1:0] & //only if there is no ipend bit <=current
ic_global_en[IRQW-1:0]; //global vector for nested interrupts

always @ (posedge clk or posedge reset)
if(reset)
ic_irq_entry[IRQW-1:0] <= {(IRQW){1'b0}};
else if(clk_en)
if(~sq_ic_wait) // safety stall signal
ic_irq_entry[IRQW-1:0] <= ic_irq_select[IRQW-1:0];// & ~ic_irq_entry[IRQW-1:0] ;

assign ic_irq =|(ic_irq_entry[IRQW-1:0]); //interrupt pipeline
assign ic_flush =|(ic_irq_select[IRQW-1:0]); //flush pipeline

[fdeutschmann]