[resolved][puzzle] close call

kuroneko

You have two cogs A and B which happen to execute a cogstop on the opposite ID (A: cogstop B, B: cogstop A). Said instructions are executed as close together as possible (i.e. having cog B making its attempt a second later is out). What happens?

1. A stops
2. B stops
3. both, A and B stop

Don't think too hard about it, just pick what you feel is right! Extra points for explaining why.

pedward

If they are synced perfectly before they call COGSTOP, since they are both hub instructions, whoever gets the hub window first kills the other. If they use a semaphore to sync up at some point, the first COG to be launched will always kill the second one, assuming that the COGID is lower. Since COGSTOP stops the system clock to that COG, it will never have the opportunity to execute the hub instruction to kill the other COG.

This is a classic race condition.

Phil Pilgrim (PhiPi)

Since cogstop is a hub instruction, and irrespective of Kuroneko posing the question, my gut tells me that whichever cog gets hub access first will be able to stop the other one, but not vice-versa. The only way that both would stop is if the hub action of the second was pipelined for execution independent of its cog actually running.

Now, since Kuroneko posed the question, my gut also tells me that the real answer is, "It depends." And what I suspect it depends upon are the relative cog IDs of A and B and by how much the cogstop access window of one lags that of the other.

-Phil

Tubular

I'm going option 3 - and I promise I didn't think too hard about it.

MagIO2

My guesswork:
The pipeline has 4 stages (needs 4 clocks), each HUB-window lasts for 2 clocks.
So, for me the question is whether the HUB instruction is prepared before the HUB window arrives and I would say yes. Otherwise 2 clocks would not be sufficient - 1 for setting the address, 1 for the action (read/write...). In other words the COGSTOP waits at stage 4 of the pipeline until the HUB-window arrives and the important things are already set in some HUB-internal registers (which instruction, which address...). So, for the actual HUB instruction execution the COG is not needed anymore.
That's why I currently would opt for 3 with the given precondition. I does not matter how far apart the HUB access-windows of the COGs are. As soon as the execution is started at the same CNT - maybe CNT+1 - both will stop.

kuroneko

No further comments it seems. OK, let's make this quick:

• the cog getting its hub window first will obviously succeed in shutting down its target
• the second cog may succeed as well provided its hub window slot is next to its target (e.g. ID_B = (ID_A+1)&7)

pedward

kuroneko wrote: »

No further comments it seems. OK, let's make this quick:

• the cog getting its hub window first will obviously succeed in shutting down its target
• the second cog may succeed as well provided its hub window slot is next to its target (e.g. ID_B = (ID_A+1)&7)

I assume this has to do with the 1 instruction COG pipeline of the Prop 1? Or does it have to do with the Hub pipelining an instruction?

kuroneko

pedward wrote: »

I assume this has to do with the 1 instruction COG pipeline of the Prop 1? Or does it have to do with the Hub pipelining an instruction?

Given a choice I'd pick the latter. After that it's pure (blackbox) guesswork. Just ran some tests using cog 1 and cog 2. The latter sets a pin high just before it calls cogstop on cog 1. What I find is that the pin goes back to low in the 6th cycle of cog 1 calling cogstop.

+--------- stop request for cog 1 latched
              |+-------- cog 2 stopped
              ||
cog 1:    [COLOR="orange"]SDe--x-R[/COLOR]
cog 2:  SDeR[COLOR="orange"]SDe--x-R[/COLOR]
  pin:   __/###\__

This suggests that cog 2 is able to latch its stop request in the hub logic before it actually gets stopped one cycle later. If the ID gap is bigger then this wont happen.

Disclaimer: This may be complete backspace but it explains observed behaviour, i.e. it's good enough for me. YMMV