A question about the propeller clocking scheme
zemkacz
Posts: 19
Hello everyone!
I am trying to understand the performance of the propeller, specifically the MIPS and understanding how each cog works.
Here is what I understand so far, please correct me if I am wrong anywhere.
-- The propeller takes the oscillator signal from an external source, say, 5 MHz to make the math easier.
-- The 5 MHz goes into a PLL, which I set to x16 to get to get 80 MHz.
I presume so far I am correct, since the data sheet states the propeller goes from DC to 80 MHz.
-- Each assembly instruction takes at least 4 cycles to complete.
-- Each cog operates at 20 MIPS when the propeller runs at 80 MHz.
Here is where I get confused.
If the propeller operates at 80 MHz, all eight cogs would supposedly run at most 10 MHz due to keeping the shared resources such as RAM and ROM accessible to only one COG at any time, preventing conflicting requests at the same time.
So, each instruction takes 4 cycles, with each cog running at 10 MHz, that would give us 2.5 MIPS per cog. This is far lower than the 20 MIPS for each cog that data sheet states.
Also, how can the propeller reach 160 MIPS when the top frequency in the chip is 80 MHz? Does it have yet another PLL which doubles the frequency inside of the propeller?
Also, what is more confusing is the hub grants access to each cog only once per 16 cycles.
"The Hub and its bus run at half the System Clock rate, giving a cog access to mutually-exclusive resources once every 16 System Clock cycles." Does this mean that each cog can fetch instructions from ROM only at 5 MHz? That would reduce the MIPS even lower to 1.25 MIPS due to the four cycle execution time per instruction.
Can anyone please help me understand the clocking scheme behind the propeller? I am eager to use this chip, but I first need to understand if one propeller can handle my processing requirements, for which I need to understand the clocking scheme.
Thank you very much for your patience!
I am trying to understand the performance of the propeller, specifically the MIPS and understanding how each cog works.
Here is what I understand so far, please correct me if I am wrong anywhere.
-- The propeller takes the oscillator signal from an external source, say, 5 MHz to make the math easier.
-- The 5 MHz goes into a PLL, which I set to x16 to get to get 80 MHz.
I presume so far I am correct, since the data sheet states the propeller goes from DC to 80 MHz.
-- Each assembly instruction takes at least 4 cycles to complete.
-- Each cog operates at 20 MIPS when the propeller runs at 80 MHz.
Here is where I get confused.
If the propeller operates at 80 MHz, all eight cogs would supposedly run at most 10 MHz due to keeping the shared resources such as RAM and ROM accessible to only one COG at any time, preventing conflicting requests at the same time.
So, each instruction takes 4 cycles, with each cog running at 10 MHz, that would give us 2.5 MIPS per cog. This is far lower than the 20 MIPS for each cog that data sheet states.
Also, how can the propeller reach 160 MIPS when the top frequency in the chip is 80 MHz? Does it have yet another PLL which doubles the frequency inside of the propeller?
Also, what is more confusing is the hub grants access to each cog only once per 16 cycles.
"The Hub and its bus run at half the System Clock rate, giving a cog access to mutually-exclusive resources once every 16 System Clock cycles." Does this mean that each cog can fetch instructions from ROM only at 5 MHz? That would reduce the MIPS even lower to 1.25 MIPS due to the four cycle execution time per instruction.
Can anyone please help me understand the clocking scheme behind the propeller? I am eager to use this chip, but I first need to understand if one propeller can handle my processing requirements, for which I need to understand the clocking scheme.
Thank you very much for your patience!
Comments
-Phil
When the Propeller operates at 80 MHz, all cogs operate simultaneously with the 80 MHz system clock and each executes at 20 MIPS. You are correct that the 8 cogs have to share resources like hub RAM and ROM, but these are handled with special instructions that do take longer than other instructions since they stall the affected cog until the time slot allocated to the cog for shared memory access comes up. These instructions can be interleaved with ordinary instructions in most cases to minimize the effect on cog throughput. Regardless, most cog programs spend most of their execution time executing instructions that do not use shared memory. Think of the shared memory much like I/O devices.
For some applications, particularly things like VGA video drivers where speed is of the essence, several cogs can be synchronized to increase throughput. Typically, one cog will be outputting a group of scan lines from a buffer within the cog's memory while the other cooperating cogs are fetching lines of text, accessing font tables, and building a group of scan lines for later output.
One extreme example uses 6 of the 8 cogs to provide a 1600 x 1200 pixel mixed text/graphics display with an optional 7th cog used to provide an overlaid cursor. This was intended as a demonstration of what can be accomplished rather than as a practical tool since it uses 6 or 7 of the 8 cogs available. Still, you could use this in a dual Propeller device with one Propeller just providing the video output and the other Propeller providing other functions.
I had no idea that the all the cogs operate at 80 MHz! That is insane if I may say so! :P
Thank you very very much for these responses, this is far better than I originally understood the propeller.
Thank you again!