What is a few clocks among friends

John Abshier

I expected the following fastspin program to out put the same number 4 times. The actual outputs were 8, 20, 18, 16. Fastspin version 3.9.22

freq = 160_000_000
  baud = 230400                     'must configure RUN command to match this
  rx = 63
  tx = 62

    
VAR
    long time

OBJ
    ser : "SmartSerial"
    
    
PUB Main
    clkset(oscmode, freq)
    ser.start(rx, tx, 0, baud)                  'start up serial terminal
    waitcnt(2 * freq)                           'wait to open terminal

    time := -cnt
    time += cnt
    ser.dec(time)
    ser.nl

    time := -cnt
    time += cnt
    ser.dec(time)
    ser.nl

    time := -cnt
    time += cnt
    ser.dec(time)
    ser.nl

    time := -cnt
    time += cnt
    ser.dec(time)
    ser.nl
    repeat

John Abshier

ersmith

Your variable "time" is a member variable of the class, and so it is stored in HUB memory. That means accesses to it depend on the HUB access window, which will vary based on the code position (we're also using the HUB to read instructions) and timing.

If you change "time" to be a local variable of the Main method then you'll get a more consistent result.

John Abshier

Thanks ersmith. With power (P2) comes responsibility (I didn't exercise).

John Abshier

kwinn

John Abshier wrote: »

Thanks ersmith. With power (P2) comes responsibility (I didn't exercise).

John Abshier

With multiple processors and shared resources we also get more complexity and more uncertainty. Gone are fixed cycle counts for some instructions.

evanh

Hub accesses can still be counted, they're just not the simple 16-clock interval the Prop1 had.

Here's the rules:
- It takes 3 clocks minimum for a WRLONG
- It takes 9 clocks minimum for a RDLONG
- For an 8-cog Prop2, each pass of a particular address in hubRAM comes around every 8 clocks.
- But, for each increment in address you also add +1 to the clock cycles to access it.

So, for example, if wanting to read two consecutive longwords you could stack one after the other and know that the second RDLONG will take its minimum of 9 clocks.

You can take advantage of WRLONG's shorter minimum by stepping in different spaced increments. Even running backwards. But mostly it will be used for other processing instructions. Conveniently those 8+1 clocks per incremental longword comes in handy by leaving exactly 6 clocks spare between each WRLONG.

NOTE: It's important to always comment it as 8+1 clocks (8 + whatever the address difference is). This is because if skipping a rotation then the new time slot is not 9x2 but 8x2+1.

evanh

PS: Obviously cogexec is the ultimate clock counting tool, but small amounts can be done as inline hubexec.
PPS: Oh, and those are longword increments I'm meaning. In terms of byte addressing it's +4 for each +1 in clock cycles.

cgracey

If you need to read or write more than one long in hub, use SETQ(2)+RDLONG/WRLONG. Each additional long after the first will only take one clock.

evanh

If using the FIFO for block reads and WRLONG for the write-back, be aware that the FIFO will snatch eight hubRAM clock cycles after every eight RFLONGs. If a WRLONG coincides then the WRLONG has to wait.

An option for most demanding scenario is cog pairing with shared lutRAM. Then the paired cog can be buffer management with block copying or both cogs could share the processing and maybe both FIFOs get used.

TonyB_

deleted

TonyB_

deleted