waitpxx detailed timing?
ags
Posts: 386
What is the timing (in clock cycles) between a pin detected high (or low) - "releasing" the waitpxx instruction and beginning the next?
From other discussions, I believe that waitpxx requires a minimum of 6 clocks. If it is like waitcnt, the comparison happens during the 4th clock (unclear what happens during the 5th) and results are written in the 6th. So for:
waitcnt value, delay
cnt is sampled during the 3rd clock or "e" clock (using modified SDeR (fetchSource/fetchDestination/execute/writeResults) terminology for waitxx instructions of SDwm.R - or fetchSource/fetchDestination/wait/match/nothing/writeResult).
With waitpxx, is INA sampled during the 3rd clock? If so, and steps similar to waitcnt occur (fetchSource/fetchDestination/sampleINA/match/nothing/writeResult) that would mean that the following instruction begins 3 clocks after the src operand matches INA.
Is this correct? I searched for waitpne and waitne but found nothing about this. Thanks.
From other discussions, I believe that waitpxx requires a minimum of 6 clocks. If it is like waitcnt, the comparison happens during the 4th clock (unclear what happens during the 5th) and results are written in the 6th. So for:
waitcnt value, delay
cnt is sampled during the 3rd clock or "e" clock (using modified SDeR (fetchSource/fetchDestination/execute/writeResults) terminology for waitxx instructions of SDwm.R - or fetchSource/fetchDestination/wait/match/nothing/writeResult).
With waitpxx, is INA sampled during the 3rd clock? If so, and steps similar to waitcnt occur (fetchSource/fetchDestination/sampleINA/match/nothing/writeResult) that would mean that the following instruction begins 3 clocks after the src operand matches INA.
Is this correct? I searched for waitpne and waitne but found nothing about this. Thanks.
Comments
Here's what the scope output looks like:
As expected, the uncertainty between the arrival time of the leading edge and recognition by the waitpeq is 12.5 ns. The amount of time it takes between that arrival and the output to the pin to register ranges between 56.25 ns and 68.75 ns (i.e. between 4.5 and 5.5 system clocks). See correction below.
-Phil
Oh, Smile! I grabbed the wrong edge. Yellow is out[0]; blue, out[1]. Here's the correct display:
The delay ranges from 6.75 to 7.75 system clocks.
Thanks for the catch!
-Phil
0
can synchronize to? Harder to measure if you don't allow other instructions between them, but you could
measure the speed of a loop like And see the frequency beyond which it suddenly slows down as synchrony is lost. For 6 cycles it should
be at clkfreq/12, but will be sensitive to duty cycle if edges are subject to unequal delays.
Here's the revised program. You can change the constants to test any pair of pins with this one:
-Phil
Back to my "how does it work?" quest, I suppose this means that INA is sampled/latched in the third clock cycle ("e" using the "SDeR" terminology) as is the case with most (all?) other instructions, and there are three more clocks that pass before waitpxx completes. This also matches what I've seen stating that waitpxx takes 6+ clocks.
Still on the "what is happening?" path, if live registers (e.g. INA) are latched in "e", and the actual comparison is done in the next clock ("e+1", or "R" for "normal instructions") and the last clock is used to write the result (if specified), then what is happening in the clock cycle in between ("e+2")? Is it the same as is happening with waitcnt (whatever that is)?