Concerning the IDLE instruction

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

Moderator: aolofsson

Concerning the IDLE instruction

Postby EggBaconAndSpam » Tue Jul 16, 2013 6:13 pm

I asked myself, might IDLE imply a GIE?
If not, which is rather likely, as nothing inside the Might Book of Reference hints at this, consider the following:

The most obvious of applications of IDLE are situations, in which the current core fulfilled whatever it was bid to do, and, in order to reduce power consumption and potentially memory bank contention, it decides to sleep for a while - naively expecting to be woken, as soon as more data to crunch on arrives.

One rather straightforward approach would be:
IDLE after checking the input buffers one last time (slave core);
Following a DMA transfer, send a Software Interrupt bit to our slave's ILATST (master core), remember that, due to the way routing works, the interrupt always arrives AFTER the last DMA write.

Simple, eh?
Well, we've got ourselves a nasty race condition! Good Job!

IF the write to ILATST arrives between the, rather flippant, IDLE instruction and the last check-o'-buffers (That is: "Do we have data to crunch on? If not, IDLE until we do."), THEN our dummy Software Interrupt Handler ends up firing early, and our little, reckless core never awakes...

Under 3 hypothetical circumstances, we might avert this bane of our existance!
1. IDLE does indeed imply GIE -> provided we conscientiously GID'ed earlier, no interrupt could possibly fire until IDLE is issued
2. GIE carries a substantial latency, therefore GIE;IDLE never leaks a single interrupt! -> what a dirty hack
3. We set a state variable (initialised to 0) right after awaking from IDLE; we leaked an interrupt, should TESTSET on that particular variable succeed in our Interrupt Routine. This leaves as in a nasty, yet manageable spot...

Any thoughts?


//edit
Hypothetical circumstance 2 might not be that bad, as that is the way ATMegas handle the issue.


// edit2
Depending on the latency of both GIE and IDLE, GIE;IDLE might leak an interrupt. (More of a state, than data, race)
If GIE;IDLE is indeed guaranteed to not leak any interrupt, then we are fine. <- Any confirmation on that? The pipeline part of your documentation doesn't mention special instructions.

// edit3
If GIE and IDLE carry out their write (to STATUS, bit 1 and 0 resp.) in the same pipeline stage, then there is exactly one clock edge where an interrupt might occur, after interrupts are enabled and before the chip goes into IDLE, therefore 'leaking' said interrupt.
Last edited by EggBaconAndSpam on Thu Jul 18, 2013 11:49 am, edited 4 times in total.
EggBaconAndSpam
 
Posts: 32
Joined: Tue Jul 16, 2013 2:39 pm

Re: Concerning the IDLE instruction

Postby aolofsson » Wed Jul 17, 2013 12:56 am

Not sure I am following you? There are no side effects to the 'idle' instruction. An 'idle' instruction puts the core in an idle state (sits there until it gets an interrupt). I Agree that an asynchronous interrupt can come in (from timer, dma completion, or ILATST from another core) at any time.

If the code includes the following sequence, what is the race exactly?

GIE;
IDLE;

Andreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: Concerning the IDLE instruction

Postby fdeutschmann » Mon Sep 23, 2013 1:58 am

I'm interested in this, too.

Andreas, the issue is that if code is operating with interrupts disabled, then attempts to enable interrupts and go to sleep waiting for an interrupt (indicating work to do), the interrupt might come between the enabling of interrupts and the idle (between GIE; and IDLE;): this results in the interrupt handler executing but then the eCore runs the IDLE instruction. This is called "leaking an interrupt", as the interrupt that was to wake you up woke you up before you went to sleep.

IF the IDLE instruction does not imply GIE, then the (only?) workaround to defensively avoid this situation is to use a timer to periodically check; this approach means overly fast results see maximal timer timeout rather than zero sleep.

Much better would be if IDLE accepted a bitmask for selectively enabling interrupts (combining a selective GIE into IDLE as an atomic instruction).
-frank
fdeutschmann
 
Posts: 26
Joined: Sun Sep 22, 2013 10:47 pm
Location: New York, NY

Re: Concerning the IDLE instruction

Postby hewsmike » Mon Sep 23, 2013 3:32 am

Not sure I see the problem, but do please advise if I've missed some crucial point .... :-)

That interrupt of concern that turns up b/w GIE and IDLE is going to involve a handler which, if I'm not mistaken, will/ought include a GIE at some point anyway ( even if only just prior to it's IRET ) and thus possibly trigger further/other interrupt handling ( whatever is suitably pending, possibly nesting of calls ) prior to said return. So all is well prior to reaching the IDLE instruction/state, meaning that you are still waiting for an interrupt to awaken from, having dealt with any/all interrupts appropriately ???

Cheers, Mike.

( edit ) Sorry, RTI not IRET .....

( edit ) And notwithstanding any decisions to block via IMASK .....
hewsmike
 
Posts: 85
Joined: Mon Dec 17, 2012 3:20 am

Re: Concerning the IDLE instruction

Postby fdeutschmann » Mon Sep 23, 2013 2:12 pm

To clarify: It Would Be Nice if...we could use IDLE as a simple form of a "sleep until an event"; that is, set up some external op, then IDLE expecting that an interrupt will wake us up so that we just continue on processing with the next instruction following the IDLE. In this scenario, the interrupt service routine is a simple RTI instruction; the isr does no actual work, just letting the RTI cause the machine to advance past the IDLE. (The docs aren't completely clear on this, but it seems that any interrupt during IDLE sets the eCore status ACTIVE, and that an RTI on an interrupt serviced from the Idle state does return to the instruction following the IDLE.)

But with the architecture as I currently understand it, when we enable interrupts prior to the IDLE instruction, we might get the desired interrupt before we execute the IDLE instruction -- which 'leaks' the interrupt as the isr does nothing but the RTI goes to the IDLE instruction, not the following instruction, which causes us to sleep forever as the event we are waiting on is a one-shot event. Thus the need for a watchdog timeout to guard against a too-quick interrupt.

It seems to me that IDLE really should enable interrupts; if IDLE doesn't enable interrupts, and IDLE is invoked while status GID is set, how can the core wakeup? Then again, this sort of dead-stop might be useful for debugging, assuming there's a debug capability to re-start the core? If this is indeed a feature, would be really nice to have a parameter on IDLE for interrupt blocking or non-blocking IDLE.

-frank
fdeutschmann
 
Posts: 26
Joined: Sun Sep 22, 2013 10:47 pm
Location: New York, NY

Re: Concerning the IDLE instruction

Postby over9000 » Mon Sep 23, 2013 3:12 pm

A hacky solution: in the interrupt handler, look at the instruction pointed to by the saved IP value on the stack. If the instruction is IDLE (and the previous instruction was GIE), then increment the IP on the stack before returning.
That's assuming that what you're describing actually has the potential to get stuck in IDLE state by having the interrupt you're waiting for come before the IDLE gets executed. After a GID are all non-maskable interrupts totally ignored, or queued up? I imagine the former, so it's not too likely your scenario will arise.
over9000
 
Posts: 98
Joined: Tue Aug 06, 2013 1:49 am

Re: Concerning the IDLE instruction

Postby tnt » Mon Sep 23, 2013 3:21 pm

There is also the possibility that with the pipelining there is no problem ... the GIE could be effectively enabled only after the IDLE has been issued and so you can't have an interrupt between the two ...
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: Concerning the IDLE instruction

Postby EggBaconAndSpam » Mon Sep 23, 2013 3:47 pm

@over9000 actually not a bad idea, not at all, if a bit hacky. concerning interrupts, the latter, provided they come from different interrupt sources. (interrupts set their bit in ILAT asynchronously, and multiple bits can be set at any given time)

@tnt well, no, sadly.
EggBaconAndSpam
 
Posts: 32
Joined: Tue Jul 16, 2013 2:39 pm

Re: Concerning the IDLE instruction

Postby tnt » Mon Sep 23, 2013 4:51 pm

How do you know that ? Do you have a reproductible test case proving otherwise ?
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: Concerning the IDLE instruction

Postby EggBaconAndSpam » Mon Sep 23, 2013 4:56 pm

forgot to mention that anywhere, andreas sent me the following:
"Yes, both update the STATUS register at E1." (concerning IDLE and GIE)
also, due to the way memory access arbitrating works, you can't necessarily expect IDLE to be issued immediately after GIE, there might be a few cycles, and thus pipeline stages, in between.
Last edited by EggBaconAndSpam on Mon Sep 23, 2013 4:59 pm, edited 1 time in total.
EggBaconAndSpam
 
Posts: 32
Joined: Tue Jul 16, 2013 2:39 pm

Next

Return to Epiphany and Parallella Q & A

Who is online

Users browsing this forum: No registered users and 17 guests

cron