Riddle about delays via nop() s

[rkompass]

Last week I found that with the RP2 Pico by adding to the program counter (PC = R15) you may jump into a table of successive nop()s to get a precisely resolved delay.
Granularity of delays there was 1 clock cycle (8 ns at 125 MHz clock), as expected.
Note that the LSB of the PC always is 0, so it makes sense to add even values only. This is no problem for resolution, as the nop() instruction takes 2 bytes like most of the Thumb instructions.

Now with the Pyboard (at 168 MHz clock) I observe that the delays with the same program have a granularity of 12 ns instead of the expected 6 ns.
Now my question (for boring X-Mas nights perhaps :-)): Does anyone have a simple explanation for this?

It superficially looks like the PC is incremented by 4 in every step.
Could it be that 2 nop() instructions are always read together (i.e. 32 bits) and executed in 2 clocks? The STM32F407 has no instruction cache, has it?

Is there another instruction that allows for a single clock resolution?
Can this resolution be transferred to a gpio pin at all or is the peripheral temporal resolution restricted by other lower clocks anyway?
In the latter case it would make less sense to mind that at all, from a practical point of view, given that the STM chips have quite elaborate timers on board.

Code:

@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)     # loop r1 times
    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)
    stop = ticks_us()
    print("Delay with k=", k, ":", ticks_diff(stop, start)/1000, "ns")

Result (on Pyboard 1.1):

Delay with k= 0 : 202.485 ns
Delay with k= 2 : 202.482 ns
Delay with k= 4 : 190.572 ns
Delay with k= 6 : 190.572 ns
Delay with k= 8 : 178.666 ns
Delay with k= 10 : 178.685 ns
Delay with k= 12 : 166.753 ns
Delay with k= 14 : 166.751 ns
Delay with k= 16 : 154.843 ns
Delay with k= 18 : 154.844 ns
Delay with k= 20 : 142.942 ns
Delay with k= 22 : 142.943 ns
Delay with k= 24 : 131.024 ns
Delay with k= 26 : 131.024 ns
Delay with k= 28 : 119.113 ns
Delay with k= 30 : 119.114 ns

[IHOXOHI]

Hey,
I don't know, I noted troubles with my only one NEW pyboard...? Have you the same behavior with one from another 'shop'?
See my results on my IXI's github page...

[mendenm]

have you tried overclocking the Pico to 168 MHz? Maybe the fetch from the flash has to wait at higher clock speeds. I would sort of expect the XIP cache to mitigate this problem, but maybe not. (Note: The Pico board runs fine at 250 MHz, as long it isn't thermally insulated).

[IHOXOHI]

I will... if it works...

[rkompass]

I overclocked the Pico to 250 Mhz and now the delays increment at 4 ns = 1 clock cycle. As naively expected.

Delay with k= 0 : 104.039 ns
Delay with k= 2 : 100.008 ns
Delay with k= 4 : 96.007 ns
Delay with k= 6 : 92.006 ns
Delay with k= 8 : 88.006 ns
Delay with k= 10 : 84.006 ns
Delay with k= 12 : 80.006 ns
Delay with k= 14 : 76.007 ns
Delay with k= 16 : 72.015 ns
Delay with k= 18 : 68.006 ns
Delay with k= 20 : 64.006 ns
Delay with k= 22 : 60.006 ns
Delay with k= 24 : 56.019 ns
Delay with k= 26 : 52.006 ns
Delay with k= 28 : 48.014 ns
Delay with k= 30 : 44.006 ns

[IHOXOHI]

For me, there is a point of calibration where the count pass from negative to positive (or 1/.)
Anormaly, this point seems to move for 2f405 on 3...

[IHOXOHI]

Your thechnic is nice... but I3m qustionning about the effect of the print... it seems that it doesn't have any effect on yours results...

[rkompass]

With the Winner Micro w600 (Cortex-M3) it's strange:

Every 2 nop()s take 3 clock cycles:
At 80 Mhz clock (cycle = 12.5 ns) it looks like this:

Delay with k= 0 : 618.737 ns
Delay with k= 2 : 617.937 ns
Delay with k= 4 : 580.033 ns
Delay with k= 6 : 580.179 ns
Delay with k= 8 : 543.171 ns
Delay with k= 10 : 542.991 ns
Delay with k= 12 : 501.051 ns
Delay with k= 14 : 501.012 ns
Delay with k= 16 : 468.021 ns
Delay with k= 18 : 463.422 ns
Delay with k= 20 : 425.444 ns
Delay with k= 22 : 425.783 ns
Delay with k= 24 : 384.329 ns
Delay with k= 26 : 384.332 ns
Delay with k= 28 : 338.604 ns
Delay with k= 30 : 338.599 ns

[IHOXOHI]

the pico has one first better score at 168MHz (1356), but for me crash at the second tray withh a poor score of 251... only 15 ºC in my room

[rkompass]

With the Pyboard down to 36 Mhz clock 2 nop()s take 2 cycles.

For an explanation I found this on Stackoverflow (basically as expected):

ALL instructions require more than one clock cycle to execute. Fetch, decode, execute. If you are running on an stm32 you are likely taking several clocks per fetch just due to the slowness of the prom, if running from ram who knows if it is 168Mhz or slower. the arm busses generally take a number of clock cycles to do anything.

Nobody talks about instruction cycles anymore because they are not deterministic. The answer is always "it depends".

It may take X hours to build a single car, but if you start building a car then 30 seconds later start building another and every 30 seconds start another then after X hours you will have a new car every 30 seconds. Does that mean it takes 30 seconds to make a car? Of course not. But it does mean that once up and running you can average a new car every 30 seconds on that production line.

That is exactly how processors work, it takes a number of clocks per instruction to run, but you pipeline them so that many are in the pipe at once so that the average is such that the core, if fed the right instructions one per clock, can complete those instructions one per clock. With branching, and slow memory/rom, you can't even expect to get that.

Tentative summary is as follows:

The Cortex M0+ appears to have no pipeline, the Cortex M3 has a pipeline, but it is not as efficient as the one of the Cortex M4.
With the Cortex M4 the pipeline is so efficient that in the end, one simple instruction is executed per clock on average.
And it looks as if the M0+ design is faster. On nop()s.
In general it would need measurements on instructions that actually do some computation/storage.

Official statements tell that:

The Arm® Cortex®-M0+ core has a two-stage pipeline (Cortex-M0, M3, and M4 have three stages). This two-stage pipeline decreases the core response time and power consumption.

• Stage 1: Fetch & Pre-Decode
• Stage 2: Main Decode & Execute

This new reduced pipeline seems to work better as explained:

When older Cortex-M cores (with a three-stage pipe) execute a conditional branch, the next instructions are no longer valid. This means that the pipeline must be flushed every time there is a branch. By moving to a two-stage pipeline, access to Flash is minimized and power consumption is lowered. Flash memory power often contributes the majority of the power consumed in a microcontroller, so any reduction in Flash accesses has a very direct effect on the total power consumed.

[mendenm]

I just realized, though, something we are overlooking here with respect to stalls. This is running from RAM, not flash, so there are no delays due to the flash XIP interface. It really is just the more efficient pipeline, as described above. The description indicates it helps with flash, but apparently with the built-in SRAM, too.

[IHOXOHI]

Thanks a lots, I will study...
For me, the speed of the memory isn't the cause... I'm on problems much slower... and there is very few instructions... I think that's a rtc-clock/speedProcessor which could not match...
???

[IHOXOHI]

but the ram could affect it, ..., it seems...

[IHOXOHI]

For me: