Syncing Cogs After Launch
pjv
Posts: 1,903
Hi All;
What is the best (short and simple) scheme to synchronize cogs after they are launched?
I wish to have all cogs run assembly code, and a stub in spin gets them all going. Then I need to have them all synchronized so that instructions in all of them execute on the same system clock edge.
It appears that as each cog is launched, it can take on one of four clock positions. Now, to synchronize them right after launch, typically one would hold them off with a "waitcnt" set to trigger some point in the future. What good and clever code schemes have been developed to effect this?
Or is there some better way, perhaps with locks or some other concept (I don't want to mess with pins and "waitpeq").
Thanks for any ideas.
Cheers,
Peter (pjv)
What is the best (short and simple) scheme to synchronize cogs after they are launched?
I wish to have all cogs run assembly code, and a stub in spin gets them all going. Then I need to have them all synchronized so that instructions in all of them execute on the same system clock edge.
It appears that as each cog is launched, it can take on one of four clock positions. Now, to synchronize them right after launch, typically one would hold them off with a "waitcnt" set to trigger some point in the future. What good and clever code schemes have been developed to effect this?
Or is there some better way, perhaps with locks or some other concept (I don't want to mess with pins and "waitpeq").
Thanks for any ideas.
Cheers,
Peter (pjv)
Comments
Just remember that any HUB accesses will nudge the cogs out of sync.
Well, thank you, but can you offer any particalar clever short piece of code to determine what count is sufficiently into the future, yet not waiting a whole 53 seconds for the system counter to wrap?
Cheers,
Peter (pjv)
http://www.realbeerbox.com/Bottle-COG-321.asp
Anyway,PJV, why worry so hard. Just read CNT, add a second or two on to it to get a time in the future. Then start your COGs passing them that future time as a parameter.
When everything is working, if one second bothers you start to reduce it until something breaks.
Relax, have a COG:)
That will not work beause the Cogs all launch (not lunch) at slightly different times, so adding a (common) value to each of them prior to the "waitcnt" leaves them as unsynchronized as they were at launch.
And I would like to release all as quickly as possible.
What I am now doing is:
mov Var,cnt
shr Var,#16 'get rid of insignificant timing ticks
add Var,#2 'make it a bit bigger (must be larger than 1 ?)
shl Var,#16 'restore gross magnitude
waitcnt Var,#0 'wait for sync
And this seems to work, but the shift magnitude needs to be big enough to see the 'future' for all Cogs.
But I was looking for something clever with locks, or simpler.
Cheers,
Peter (pjv)
I think Heater had something like this in mind:
PUB MAIN | start_time start_time := ( clkfreq / 2 + cnt ) ' cnt value everyone should use cog1 := cognew(@cog1_code,@start_time) 'Launch new cog cog2 := cognew(@cog2_code,@start_time) 'Launch new cog DAT cog1_code rdlong cog1_start, par waitcnt cog1_start, #100 ' wait here until start_time synchronized code goes here cog1_start long 0 DAT cog2_code rdlong cog2_start, par waitcnt cog2_start, #100 ' wait here until start_time synchronized code goes here cog2_start long 0Oh, wait, I may have misread that.
What could be simpler? Don't foregt that CNT is globally available to all COGs, they all see the same value at the same time.
In your main spin code:
1) Read the CNT value.
2) Add a second or two on to it to get a time in the future.
3) Start your COGs, passing them that future time as a parameter through PAR.
Yes they all launch at slightly different times, but we don't care because...In your COG PASM code:
1) Read that future time value from PAR (or somewhere it points to)
2) Waitcnt for that future time.
3) Do you synched code.
I think pgbpsu's code is heading in that direction. That code may need some "ORG 0" statements at the start of each PASM section
Given that PASM instructions take four clocks can we be sure that after the waitcnt that hey all start in step or is there a possibility of a 1, 2 or 3 clock difference? I would hope not but with doing the experiment I may never believe it.
K2, I don't think I've ever had the pleasure of that kind of COG. Wonder if they could deliver some to Finland?
Use a number that all can get from Hub Ram!....... DUH!
Obviously I'm too focused on assembler .... I was trying for each Cog to independently figure out its own, and you have pointed me to an obvious answer. Although my method appears to work, yours is simpler. Thanks
Cheers,
Peter (pjv)
I just tested it, and it works perfectly.
So thanks to you both. One of these days I will start using Spin.
Cheers,
Peter (pjv)
Great stuff.
Do you have the possibility to measure how closely synched he slave COGs are? Say by having the slave COGs toggle different pins and check the timing between edges with a scope or LSA.
Yes, fortunately my tools will get down to picoseconds, but I only own one low-cap (1.5 pf) active probe because they cost about $2K each, so I cannot do a pin to pin comparison with that. But the regular scope probes are good for a nano second or two, and I can extrapolate when running multiple identical probes. The 16 channel parallel probe yields an uncertainty of 2 nano sec.
All said, there is about a 0.8-ish nano second transit delay from one cog's output to the next as the out state is passed along the OR chain.
Very early on in my propeller experiments (years ago) I chatted with Chip about this, and he confirmed that, and if I recall correctly, he stated there was a reversal in the chain sequence, half way along.
I can have closer look at this for you if you want.
Cheers,
Peter (pjv)
Wow, I would have been happy with a result to within a clock period or so. Glad to hear it works so well.