Concerning the IDLE instruction

Any technical questions about the Epiphany chip and Parallella HW Platform.

Moderator: aolofsson

Re: Concerning the IDLE instruction

Postby tnt » Tue Sep 24, 2013 7:25 am

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 ...
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: Concerning the IDLE instruction

Postby EggBaconAndSpam » Tue Sep 24, 2013 10:24 am

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.
EggBaconAndSpam
 
Posts: 32
Joined: Tue Jul 16, 2013 2:39 pm

Re: Concerning the IDLE instruction

Postby tnt » Tue Sep 24, 2013 1:52 pm

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)
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: Concerning the IDLE instruction

Postby EggBaconAndSpam » Tue Sep 24, 2013 2:47 pm

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.
EggBaconAndSpam
 
Posts: 32
Joined: Tue Jul 16, 2013 2:39 pm

Re: Concerning the IDLE instruction

Postby notzed » Thu Sep 26, 2013 1:15 am

Why would you want to enable interrupts before an IDLE? If the interrupt disabled state is effectively your mutex, you don't want to unlock the mutex before cond-wait (and no work-arounds will work properly). After IDLE "returns" you can then either enable interrupts to let the ISR run (smaller code) or handle it directly (lower latency).

Can adapteva clarify what this means in the description of IDLE?
Code: Select all
while (!INTERRUPTED) {}

Does it mean this?
Code: Select all
while (!ILAT) {}


If this is the case (and why wouldn't it be?), then you could use a software interrupt to communicate from the interrupt handler to the code in a more controlled way. The software interrupt should be masked so that no handler is executed, and then the ILAT bit is cleared by the user code (and only by the user code).

This would let you enable interrupts before idle, if so desired.
notzed
 
Posts: 331
Joined: Mon Dec 17, 2012 12:28 am
Location: Australia

Re: Concerning the IDLE instruction

Postby aolofsson » Thu Sep 26, 2013 3:05 am

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 :D

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
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: Concerning the IDLE instruction

Postby fdeutschmann » Thu Oct 03, 2013 9:53 pm

THANK YOU!!

aolofsson wrote: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 :D

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
 
Posts: 26
Joined: Sun Sep 22, 2013 10:47 pm
Location: New York, NY

Previous

Return to Epiphany and Parallella Q & A

Who is online

Users browsing this forum: No registered users and 4 guests

cron