Inter-Core Synchronization

The following page provides an example of synchronizing execution between between heterogeneous Cores.

Setup

Similar to the other Inter-Core example, this example requires Lumorphix to be built to support more than one Core, but to have the locking channel (XBar Lock) between at least two of them enabled.

To check this (and the lock channel configuration), review the output of the ‘list|xbar_cfg’ command:

LUA

[ #1 ] / list|xbar_cfg

  XBAR LOCK

                |  -  |CORE2|
         LOCK EN|     |  X  |
      LOCK DEPTH|     |  1  |
       UNLOCK EN|     |     |
    UNLOCK DEPTH|     |     |


  XBAR DATA

                |  -  |CORE2|
           TX EN|     |  X  |
   TX FIFO DEPTH|     |  16 |
           RX EN|     |  X  |
   RX FIFO DEPTH|     |  8  |

From this output we can see that the forward locking barrier between Core #1 and Core #2 is enabled - the forward path from Core #1 to Core #2 has been configured to support a single lock (depth of one).

Script

As detailed in the API section, all lock barriers are initialised to the ‘unlocked' state upon power-on. Thus, the first example details controlling the execution of Core #2 from Core #1. Again, the core number prompt is included in the example, for clarity.

LUA

[ #2 ] $ import("all")
[ #2 ] $ unlock(CORE1)

At this point, Core #2 will hang, as it attempted to unlock the forward barrier, which was already unlocked. It is essentially now waiting for Core #1 to lock the forward locking barrier (upon which it can then immediately unlock the barrier). Switching over to Core #1:

LUA

[ #1 ] $ import("all")
[ #1 ] $ lock(CORE2)

If the user comms channel is switched back to Core #2, one can confirm Core #2 is no longer hanging and has resumed execution.

Next, the reverse is demonstrated:

LUA

[ #1 ] $ lock(CORE2)
[ #1 ] $ lock(CORE2)

At this point, Core #1 will hang, as it attempted to lock the forward barrier, which it had already locked. It is essentially now waiting for Core #2 to unlock the forward locking barrier (upon which it can then immediately lock the barrier). Switching over to Core #2:

LUA

[ #2 ] $ unlock(CORE1)

Again, switching user comms channel, one can confirm Core #1 is no longer hanging and has resumed execution.

The Lumorphix API offers locking and unlocking functions that do not hang if the attempt fails (non-blocking).

References

API