Cogs Slow Down Prop?
Humanoido
Posts: 5,770
Let's say you have a simple real world program (no multi-tasking) running only in cog 0, written in spin and it does some short delays. Cogs 1 through 7 are off. You measure the code including the delays and it's running at 480.6 clock cycles per program instruction (average). The clock is running 100 MHz. The IPS is 208,073.
Now put a similar program in cog 1 and run both programs in cog 0 and cog 1 at the same time. Are we looking at half speed IPS in each cog (104,036.5)?
According to the manual, the cogs maintain the same time reference.
Thanks for your reply.
Humanoido
Now put a similar program in cog 1 and run both programs in cog 0 and cog 1 at the same time. Are we looking at half speed IPS in each cog (104,036.5)?
According to the manual, the cogs maintain the same time reference.
Thanks for your reply.
Humanoido
Propeller Manual v1.1 p22: All eight cogs are driven from the same clock source, the System Clock, so they each maintain the same time reference and all active cogs execute instructions simultaneously.
Comments
That is the beauty of the Prop. Activity starting up somewhere else in you application will not mess up the timing determinism of your currently running code.
Provided of course they don't have interaction through shared pins or shared HUB memory locations and they don't mess with clock settings.
The cogs run at full speed (one instruction every 50ns at 80MHz) regardless of how many cogs are active.
The only instructions that are affected by other cogs are the "hub" instructions that access shared (hub) memory (RDxxxx and WRxxxx). There's a synchronization mechanism used by these instructions that causes the initiating cog to stall (wait) until the cog's access slot occurs (once every 16 system clock cycles). That's why these instructions are shown with a variable execution time. They will stall for a period of time dependent on the current state of the synchronization mechanism and the timing relationship between the initiating cog and the time slot for the cog. Note that the access slots are fixed and are present whether the cog is active or not. This allows deterministic execution regardless of the state of the other cog.
There are some other instructions that have variable execution times, but these are dependent on external events (WAITPNE, WAITPEQ, WAITCNT). WAITVID's delays depend on how the video hardware for the cog is configured.
I know what you are saying but I think this statement could be worded better:
In fact RDxxxx and WRxxxx are NOT affected by the activity of other COGs.
Which you have emphasized a bit further on with:
Just a nitpick.
The hub memory access instructions have a variable execution time. The executing cog is forced to wait until its hub access "slot" occurs. See the Propeller Manual or the datasheet for a diagram that shows this process.