Precisely Synchronizing Low Rate SM to Async Edge - Arm Thumb help needed

[mungewell]

Working away on my Timing/Clock projects, where i have a low-ish speed (12KHz clock) PIO StateMachine which I need/want to synchronize to a trigger edge... just triggering when the input goes high (or low) results in inaccurate timing, in that the delta between StateMachine clock and edge can be from zero to up-to one period.

I've worked out a good solution, but need some Arm Thumb help to optimize. It works like this....

• Full speed (SYS_CLK) state machine tracks edge, and sets a PIO IRQ.
• Medium speed state machine see PIO IRQ and starts counting - it know what low speed clock is. Before it finishes counting out the period it causes a CPU IRQ.
• The CPU IRQ handler stalls, waiting for the Medium speed SM to reach the end of the count (which it determines by looking at SM-0 current address), at which point it asserts the reset to CLOCK_DIV and starts the low speed SM.
• The low speed SM now starts 'exactly' 1 period after the trigger, whilst still clocking at the low rate but closely aligned to the correct timing.

This looks like this:

Code is:
precision.py.txt

Where I need some help is in the IRQ handler, which is in Thumb ASM.

1). To add code to enable/disable IRQs, so that that it is not interrupted by higher priority IRQ.

2). Increase the speed of testing for the '0' address of the medium speed SM. This is when the handler knows to enable the low speed SM. This really isn't fast enough, SM will spend 10 SYS_CLKs at this 'address' but I would like the trigger to be quicker.

    label   (wait_for_it)
    ldr     (r3, [r1, 0])       # value from 0x502000d4=SM0_ADDR into r3
    cmp     (r3, 0x18)          # NOTE: this is SM-0 address
    bne     (wait_for_it)

3). BONUS FEATURE - if you look at the fast SM it has a 'trap' for detecting the relative phase of the 12MHz medium speed SM. If the IRQ handler can be speed-up, then it can use this information to finely adjust the moment when it enables the Slow SM.

def start_from_pin_falling():
    wrap_target()
    irq(4)

    wait(1, pin, 0)
    wait(0, pin, 0)

    irq(clear, 4) [9]               # Trigger Sync

    label("phase1")                 # will stick at this 'address' depending
    jmp(pin, "phase1")              # on when exactly the Sync occurs
    label("phase2")
    jmp(pin, "phase2")
    label("phase3")
    jmp(pin, "phase3")
    label("phase4")
    jmp(pin, "phase4")
    label("phase5")
    jmp(pin, "phase5")
    label("phase6")
    jmp(pin, "phase6")
    label("phase7")
    jmp(pin, "phase7")
    label("phase8")
    jmp(pin, "phase8")
    label("phase9")
    jmp(pin, "phase9")
    label("phase10")
    jmp(pin, "phase10")

Here's a quick plot, showing that (even as-is) the code is really good at starting the slow SM at the right point/time:

[mungewell]

On '2).' if that's the fastest we can process, then we can live with it. I visually un-rolled the code and see that there's 3 'flows' where the code will correctly detect.

If we expand the code to read the SM0-Address twice (into different registers), then we can both detect the right address and then compare the two-copies to determine when it changed. This results in four 'flows' but looks like code can align itself to the 12MHz clock in the State-Machine.

In the plot the 'green' reads show where the correct value is read, 'blue' is additional nop() steps which are then added accordingly. The 'red' is the moment where we might write to the 'Div-Reset', which is preceded by 4 steps ('orange') which can be used to process/jmp according to the 'phase' detected of SM-0 vs SM-1, ie against the 120MHz SYS clock.

For '3).' a lower SM-1 address means SM-0 clock is earlier (as it asserted GPIO earlier), this would need less added delay. A higher SM-1 address means that SM-0 clock is later and thus we need to add delay before 'Div-Reset'. I think we can do something like:

ldr (r3, [r2, 0]) # read SM-1 Address
sub (r3, 0x15, r3) # subtract current address from end address of SM-1
lsl (r3, r3, 1)   # times 2, as 16bit op-codes
jmp("nops", r3) # vectored jump...
nop()
nop()
nop()
nop()
nop()
nop()
nop()
nop()
nop()
nop()
str     (r2, [r0, 0])

Note: need to read/store SM-1 current address, before SM-0 de-asserts it's GPIO

[mungewell]

Slightly tweaked as it appears the 'Branch' will take 2 cycles when taken (and 1 when not)....
http://www.breatharian.eu/hw/rasppicoasm/index_en.html

Same page suggest that ADD PC,Rm is a thing, but this errors on loading... suggestions?

I have the 'vector' in R6 as computed with

    ldr     (r6, [r7, 0xc])     # loads 0x502000ec into r1
    ldr     (r6, [r6, 0])       # value from 0x502000ec=SM1_ADDR into r6
    mov     (r3, 0x18)          # NOTE: this is SM-1 address 'top'
    sub     (r6, r3, r6)
    mov     (r3, 1)
    lsl     (r6, r3)            # double value as each 'nop()' instruction is 16bit wide

[mungewell]

here's the revised 'un-rolled' image of the code, and the code itself.

precision.py.txt

This is getting close, but there is still an unknown timing bug. It's slightly off from the expected 83.3333 us.

I am still looking for Arm Thumb help for:

1). Disable/Enable other IRQs interrupting my ISR.

3). How to do a 'vectored' jump into code, ie to jump over a (changable) number of nops().

[rkompass]

Hello @mungewell

I tried this interesting problem:

3). How to do a 'vectored' jump into code, ie to jump over a (changable) number of nops().

and found that you may adjust your delays to the clock resolution, as intended:

@micropython.asm_thumb
def asm_udelay(r0, r1):
    b(START)
    label(DELAY)
    data(2, 0x4487)  # add(r15, r15, r0)
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    nop()
    bx(lr)
    label(START)
    bl(DELAY)
    sub(r1, 1)
    cmp(r1, 1)
    bge(START)

from time import ticks_us, ticks_diff

for k in range(0, 32, 2):
    start = ticks_us()
    asm_udelay(k, 1_000_000)       # use 1000000 iterations for precise measurement
    stop = ticks_us()
    print("Delay with k=", k, ":", ticks_diff(stop, start)/1000, "ns")

gives:

Delay with k= 0 : 208.032 ns
Delay with k= 2 : 200.016 ns
Delay with k= 4 : 192.012 ns
Delay with k= 6 : 184.012 ns
Delay with k= 8 : 176.028 ns
Delay with k= 10 : 168.013 ns
Delay with k= 12 : 160.012 ns
Delay with k= 14 : 152.012 ns
Delay with k= 16 : 144.012 ns
Delay with k= 18 : 136.011 ns
Delay with k= 20 : 128.013 ns
Delay with k= 22 : 120.042 ns
Delay with k= 24 : 112.013 ns
Delay with k= 26 : 104.03 ns
Delay with k= 28 : 96.021 ns
Delay with k= 30 : 88.013 ns

So you have the 8 ns granularity which is in accordance with the 125 MHz clock cycle.

For enabling and disabling interrupts you should use

Currently the cpsie() and cpsid() functions are partially implemented. They require but ignore the flags argument and serve as a means of enabling and disabling interrupts.

which is taken from the docs.

[mungewell]

@rkompass I think this might be the answer, I'd never of guessed to use data().

I'm getting really close on a working solution.... I'll post code when I have checked a few more details.

[mungewell]

Here's the (current) code.
precision.py.txt

I had success with a 'spread' of 16ns in over 200 start-up cycles!

I still need to add in the IRQ disable/enable.

[mungewell]

If anyone is following along, or finds this in the future, I have used this method in my project and written up the scheme here:

https://github.com/mungewell/pico-irig/blob/main/docs/precision_trigger.md

[mungewell]

I released that with 'B' taking 2 cycles when 'taken', it means that there are actually 6 possible flows. I will need to adjust my scheme a bit...

[mungewell]

So here's the new scheme... testing with just one 'read' to start with gives us 4 possible flows. Then using the '2 cycle when taken' branch to insert delays to align the CPU (120MHz) with SM-0 (at 12MHz).
Branches 'not taken' are high-lighted grey.

This gives a trigger like:

And looks to be quite good over successive runs, with a spread of ~80ns... so maybe still a bug to iron out.

      1 0.00008333
     44 0.00008334
     30 0.00008335
     43 0.00008336
     52 0.00008337
     29 0.00008338
     51 0.00008339
      9 0.00008340
     10 0.00008341

[mungewell]

Another day, and another realization.... ldr() is also taking 2 cycles. Damn, oh well another schema needed.

In this one there are 5 possible 'flows' and the sync process takes 3 SM-0 cycles. But after all that it looks like we have the solution.

An test of over 200 power up cycles gave results where the spread of the measured 'trigger to SM-4' starting gave a spread of 16ns

      8 0.0000833220
     25 0.0000833240
     12 0.0000833260
     25 0.0000833280
     24 0.0000833300
     22 0.0000833320
     40 0.0000833340
     32 0.0000833360
     32 0.0000833380
     19 0.0000833400

Not sure how we end up with smaller that CPU steps, but the signal is asynchronous so that probably can affect how it is sampled (through the double clocked buffers) and the Saleae possibly has some variation in measurement (at max 500MHz sample time).