I think what arg001 is describing is that the input signal (in this case the pin being WAIT-ed for) controls a parallel mux, which switches between the current PC and the next instruction PC. In reality it is likely even more complicated than that. Because it is in parallel, it means that (in the case of 5 bit PC), 5 multiplexers, all using the input pin as control signal, switch between the PC and PC+1 under its control. Because the glitched signal I feed is most likely in a level between high and low (noise, low-freq), this causes some of the multiplexers to select the current PC and some to select PC+1 (each mux has slightly different input levels and delays). Though it is also possible this error could propagate through the mux itself and give some neither high nor low state to the stages further on, which might be likely happening. If this was a gray code for example, there would be only 1 bit difference between consecutive values. But if binary encoding is used, then the difference between PC = 01111 and 10000 is big, and if the MSb mux selects the former and the remaining ones - the latter, we get 00000, while in the opposite case we get 11111.
The reason I say it is likely even more complicated than that is that the PC I am using are 22 and 23 (maybe also 24 depending on how the .wrap is implemented) and they are in binary: 10110, 10111, 11000, and if 24 is not involved, then bit 3 is always 0, so the min and max addr to get would be 22 and 23 again. While if 24 is involved, then 10000 (16) and 11110 (30), but I most often get 0 (assuming that the PIO mem is in advance filled with instr that jump to themselves, so jumping anywhere in it, should remain on the same instr.
I would assume that the reason that high frequency signals rarely cause this is their fast transitions - so they are rarely sampled in the area between high and low, unless that is really accurately adjusted but even then, one would be trying to catch a transition which happens very fast. Instead it is much easier to happen when the transition last much longer. And, of course, as arg001 said, if the input signal is synchronized with the CLK_SYS, and is offset such that the sampling point is not on the transitions (clean high or low) then this problem won't happen. The trick, perhaps, to getting a metastable state would be to feed a variable level analog signal (maybe from a manually-controlled potentiometer or a DAC) which to be around the middle of the high and low input levels. And have the RP PIO sample that signal on every instruction to increase the chance of sampling when it is at just the 'right' level.
The actual test setup I am using is much simpler - I just connect the input pin (wire) to a 'not-too-clean' ground connection and after sliding it on it for a few seconds, it seems to cause the right noise/level to trigger the effect. It so far has never happened with input synchronizers enabled, and it doesn't seem to be affected much by anything else.
The reason I say it is likely even more complicated than that is that the PC I am using are 22 and 23 (maybe also 24 depending on how the .wrap is implemented) and they are in binary: 10110, 10111, 11000, and if 24 is not involved, then bit 3 is always 0, so the min and max addr to get would be 22 and 23 again. While if 24 is involved, then 10000 (16) and 11110 (30), but I most often get 0 (assuming that the PIO mem is in advance filled with instr that jump to themselves, so jumping anywhere in it, should remain on the same instr.
I would assume that the reason that high frequency signals rarely cause this is their fast transitions - so they are rarely sampled in the area between high and low, unless that is really accurately adjusted but even then, one would be trying to catch a transition which happens very fast. Instead it is much easier to happen when the transition last much longer. And, of course, as arg001 said, if the input signal is synchronized with the CLK_SYS, and is offset such that the sampling point is not on the transitions (clean high or low) then this problem won't happen. The trick, perhaps, to getting a metastable state would be to feed a variable level analog signal (maybe from a manually-controlled potentiometer or a DAC) which to be around the middle of the high and low input levels. And have the RP PIO sample that signal on every instruction to increase the chance of sampling when it is at just the 'right' level.
The actual test setup I am using is much simpler - I just connect the input pin (wire) to a 'not-too-clean' ground connection and after sliding it on it for a few seconds, it seems to cause the right noise/level to trigger the effect. It so far has never happened with input synchronizers enabled, and it doesn't seem to be affected much by anything else.
Statistics: Posted by wisi — Sun Jun 01, 2025 2:58 am