HUB/COG Data Transfer Timing

greybeard

I recently had the occasion to discuss the Propeller architecture with an experienced programmer but Propeller neophyte. It made me think in more detail about the HUB/COG data transfer process and I went back to the manual for clarification.

The following is copied from the manual and is decorated with my interpretations indented, bold and in italics (I hope). Corrections would be appreciated.

Assembly Language Reference Notes for Master Table
Note 1: Clock Cycles for Hub Instructions
Hub instructions require 8 to 23 clock cycles to execute depending on the relation between the cog’s hub access window and the instruction’s moment of execution. The Hub provides a hub access window to each cog every 16 clocks.

The HUB uses two clock cycles to grant access to each COG in a round robin fashion. Perhaps the first clock to move the focus from on COG to the next COG and one clock to move data between COG and HUB memory, if any is to be moved – OR NOT.

Because each cog runs independently of the Hub, it must sync to the Hub when executing a hub instruction. The first hub instruction in a sequence will take from 0 to 15 clocks to sync up to the hub access window, and 8 clocks afterwards to execute; thus the 8 to 23 (15 + 8) clock cycles to execute.

Now I am confused. This implies that the COG uses 8 clocks to execute the HUB instruction after HUB access is established. This is impossible if the HUB access shifts to the next COG after two clock cycles. MY INTERPRETATION is that it takes 8 clock cycles for the COG to set up the HUB access request then the COG pauses until the HUB services the request.

After the first hub instruction, there will be 8 (16 – 8) free clocks before a subsequent hub access window arrives for that cog; enough time to execute two 4-clock instructions without missing the next hub access window.

I like my interpretation better. At the end of the HUB service request there is 16 clock cycles before there will be another HUB access granted. This is enough time for two, 4 clock cycles operations and one, 8 clock cycle HUB service request: just in time for the next HUB access.

To minimize clock waste, you can insert two normal instructions between any two otherwise-contiguous hub instructions without any increase in execution time. Beware that hub instructions can cause execution timing to appear indeterminate;

HUB access is determinant in that it take place every 16 clock cycles. What is indeterminate is the length of time that access is granted after the HUB service is requested, i.e. after a HUB instruction is encountered by the COG. HUB access may be granted in as few as 1 clock cycle or a maximum of 16 clock cycles.

kwinn

I think your explanation is closer to the actual sequence of events. I suspect the wait is actually occurring somewhere in the middle of the 8 cycle hub op. Makes sense that some initial cycles are needed to set up the hub access, then there is a wait for hub access, which is then followed by however many cycles are required to execute the actual read or write.

Cluso99

greybeard,
Not only is your sequence of events clearer, it is in fact the way it works (having examined the Verilog equivalent code for the P1V).

However beware that a few instructions can be longer than 4 clocks, such as a jump that does not jump (eg djnz/djz takes just 4 clocks if taken and 8 if falls thru because the result of the decrement is zero). Note that conditional execution instructions (ie if_z, if_c, etc) is 4 clocks when the condition is not met (ie the instruction is not executed).

Hope this helps.

potatohead

The waitvid is more than 4 clocks too. Pretty sure the default assumption is 7, but it can actually be as low as 5, and or not exist at all, if one wants to align the framing of the pixels to the system clock and instruction cycles. (Seen long ago in Linus early Propeller efforts, and more recently in Kureniko's (spelling?) Waitvid Hand Off Point drivers)