Concerning the IDLE instruction
Posted: 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.
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.