Hub instruction timing

Sanderling

Hi,
I am trying to understand hub instruction timing. If I understand things correctly then each hub instruction takes 7 system clocks and of these 2 system clocks will actually tie up the hub shared resources. The question is: are these always the same relative clocks regardless of whether it is a read or a write hub instruction. Certainly the documentation implies this is the case - at least it implies that you always have 9 available·clocks between successive hub instructions. Any help much appreciated.

CardboardGuru

Each cog has access to the hub for 2 clock cycles, in sequence. 8 cogs = 16 cycles.

With that 2 cycles, a cog can do one WR or RD instruction (or one of the other hub operations). Yes, the same clock cycles regardless of whether it's a read or a write.

So once it has done a hub operation, it has 16-7 = 9 cycles before it can start the next one. Which is time to do 2 normal operations with no performance penalty when streaming data to/from the hub.

Jasper_M

I think it's always the two last clocks that are used for the actual hub access (and I guess that the clock before that is spent in some wait state... just a gues...). loops like

loop wrlong
       nop
       nop
       rdlong 
       nop
       jmp #loop

can be done with no performance penalty. It doesn't really matter which hubop is used.
Oh, and number of instructions between 2 hub instructions can be 2+4n with no performance penalty, eg. 2, 6, 10, ...

ciphernet

...does that mean that if I have four COG´s with·the exact same code running, can I then expect that the four COG´s can access the HUB in the exact same timeframe at every HUB cycle for getting parameters from the HUB with WDLONG and RDLONG commands to maintain synchronized?

Jan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)

Mike Green

Basically you're correct. The several programs will be accessing the hub memory at different times, but should remain in sync with each other. One cog would access the hub at time T, the next cog would access the hub at time T+2, the next at T+4, etc. The first cog would get access again at T+16 which would be 4 instructions later since each instruction takes 4 cycles.

You can keep synchronization among the cogs by using the memory access instructions or the WAITCNT instruction which allows pauses in terms of a number of clock cycles.

ciphernet

Hi Mike,

Great... Want I wanted to know. Thanks a bunch!!


Jan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)