Propeller: Synchronising two or more Cogs

Aim: to start up two Cogs using Spin code (by calling the cognew function twice) and then influence the phase (for want of a better word) difference between execution cycles on the two Cogs.

In other words, when two Cogs are made to toggle a pin each, is it possible to force the Cogs to toggle at the same time?  Equally, is it possible to make them toggle the pins out of synchrony with each-other?

I needed a simple way to test the theorem.  If I have one Cog running a simple tight-loop that toggles a pin each iteration, then I should be able to run another Cog that does basically the same thing but alter it slightly so that before starting the loop add a delay until a time when the second Cog is "in phase" with the first Cog.  

If it works then both Cogs should end up toggling the pins on the same global clock cycle.

I wrote the following code to try this out...

CON
  _clkmode = RCFAST    

PUB Main 

  cognew(@METRONOME, 1)
  cognew(@MODULATED, 0)                       

DAT                          

'FIRST COG's task...

                        org     0                
METRONOME                      
                        mov     dira, metronome_pin
                        mov     outa, #0
                        mov     counta, #256

:a                      xor     outa, metronome_pin
                        djnz    counta, #:a

                        waitpeq $, #0                       

metronome_pin           long    |< 0
counta                  res     1

                        fit                                                





'SECOND COG's task...


                        org     0                
MODULATED
                        or      dira, modulated_pin
                        mov     outa, #0
                        mov     countb, #64   'number of iterations before the delay
                        mov     countc, #64   'number of iterations after the delay

:b                      xor     outa, modulated_pin       'tight loop toggling a pin
                        djnz    countb, #:b          

                        ' << cleverly chosen time delay here >>
                        mov     time, cnt
                        add     time, #17     'minimum value is 9.  Choose this carefully in order to synchronise your cogs 
                        waitcnt time, 0
                        'time delay code ends   

                        'NOW the two cogs should be IN PHASE! :)

:c                      xor     outa, modulated_pin       'tight loop toggling a pin
                        djnz    countc, #:c

                        waitpeq $, #0    'sleep forever  

modulated_pin           long    |< 1
time                    res     1
countb                  res     1 
countc                  res     1

                        fit                                                

This code isn't very complex, it should run on a bare chip and uses the internal timer.  In fact using the internal timer is recommended because it the slow clock rate makes it easier to measure the exact timings of the pin states using a logic analyser!  I used my marvellous "Saleae Logic" (go buy one right now, seriously).

The following screenshots show the output of the two Propeller IO pins, but first a little explanation of the code is in order, since Propeller Assembly language (PASM) might be an alien language for some readers...

I have created a pair of Cog tasks named METRONOME and MODULATED.  Cog 1 begins running the METRONOME code first, followed shortly afterwards by Cog 0 being restarted and running the MODULATED task.

Each Cog task toggles a different pin on the Propeller.  METRONOME starts first and toggles pin P0.  MODULATED starts a moment later and toggles pin P1 as soon as it starts, then takes a short delay where it stops toggling.  After the delay it resumes toggling again but this time it's instruction execution "phase" has been adjusted to be synchronised with the METRONOME task.

Because Spin is an interpreted language, it is not obvious how many clock cycles elapse between METRONOME starting and MODULATED starting.  We know that both cogs will eventually be running simultaneously but there will be some relatively large time offset between them.

Take a look at the Logic analyser's recordings of P0 and P1 over time...

What we see here is that during the first loop ("b") in the MODULATED task, the pin toggling is out of phase with the METRONOME task on the other Cog.  For my purposes I wanted to be able to rectify this so that future pin toggling happens in phase with the METRONOME task.

We have a number of facts at our disposal now...
1) Both Cogs are running at the same clock frequency.
2) Propeller Cogs execute XOR instructions and non-jumping DJNZ instructions in 4 clock cycles each.  So each iteration of the toggling loops take 8 clock cycles each - this is a fixed value.
3) Hub instructions can elapse an amount of time that is an odd number of clock cycles.

Given these facts we can logically influence the phase difference between the instruction execution time on two separate cogs by as little as 1 clock cycles (remember that most instructions are 4 clocks in duration).

Turns out that the WAITCNT instruction gives you single-clock-cycle timing resolution, although this isn't explicitly stated in the datasheet or the manual for the Propeller P8X32A chip, as far as I am aware.

The Solution...

mov     time, cnt
add     time, #17

waitcnt time, 0

The "#17" seen here is the offset (in clock cycles) into the future to make the Cog wait until.  Seventeen is arbitrary for this experiment.  Using numbers smaller than 9 will cause the waitcnt mechanism to wrap around it's 32 bits worth of timing counter and this would cause many many hours of fruitless inactivity, so don't use numbers less than 9.

For this super-simple experiment 17 is good enough to sync up these two very tight loops.  If your loops take longer then you'll need to select a delay that allows your slower loop to wait until the faster loop to get back into a state that can be "joined" by the slow loop.  The delay could be up into the thousands or millions if you're using very long loops or using high clock speeds with external crystals and high PLL multipliers.

The Conclusion...

It is possible to change the phase relationship between two or more Cogs that are both running assembler code.  This is potentially very handy if you're having some weird timing issues on your multi-Cog applications.  If in doubt, get the logic analyser out!

This isn't a particularly advanced topic though, I just went into this amount of detail because it's quite good fun to look deeply into the Propeller anyway, and who knows, it might be useful to someone somewhere.

If this is useful to you then please leave a comment and let me know.

Good luck :)