Limits of Freqency and Time Measurements using Prop Pin(s)
jmg
Posts: 15,185
Expanding from the other topic, and on AN001, which only covers a few cases, what are the limits of what you can use Multiple timers and pins, to achieve ?
Example : AN001 mentions POSEDGE and NEGEDGE which I think give one SysCLK pulse per IP edge, so effectively increments at the Pin Frequency, but there is no mention/example of this edge doing a time-capture ?
Also not mentioned is the maximum Pin freq, but normal here would be H/L for 1 SysClk, so 80MHz would limit this Pin-Edge-Count to 40MHz tops ?.
Config registers have two 5 bit fields for each CTR, so that allows any-pin mapping.
(buried pins would be nice here)
32 bit uC allow things like Clear On Capture, some have capture FIFOs and some have extended edge precision to 1ns, 350ps or even 150ps
How close can the combination of HW and SW get to a good Timer Block ?
Highest Frequency, limits on repetition rates for Pulse Width, or Period snapshots ?
Example : AN001 mentions POSEDGE and NEGEDGE which I think give one SysCLK pulse per IP edge, so effectively increments at the Pin Frequency, but there is no mention/example of this edge doing a time-capture ?
Also not mentioned is the maximum Pin freq, but normal here would be H/L for 1 SysClk, so 80MHz would limit this Pin-Edge-Count to 40MHz tops ?.
Config registers have two 5 bit fields for each CTR, so that allows any-pin mapping.
(buried pins would be nice here)
32 bit uC allow things like Clear On Capture, some have capture FIFOs and some have extended edge precision to 1ns, 350ps or even 150ps
How close can the combination of HW and SW get to a good Timer Block ?
Highest Frequency, limits on repetition rates for Pulse Width, or Period snapshots ?
Comments
CON PIN = 0 'Use A0 for pulse input. DAT mov ctra,ctra0 mov frqa,#1 ... waitpne pinmask,pinmask 'Wait for pin to go low. mov phsa,#0 'Clear counter. waitpeq pinmask,pinmask 'Wait for pin to go high, waitpne pinmask,pinmask ' then low again. mov width,phsa 'Read width of pulse. ... ctra0 long %01000 << 26 | PIN 'Count only while PIN is high. pinmask long 1 << PIN 'Mask for PIN.As you can see, some minimal code support is necessary, and you will have to account for that code overhead when computing the minimum time allowed between pulses.-Phil
Manual says 5+ (+what?) for WAIT- and 4 for MOV, so if we assume 5+ means it grows by one clk per wait, and we want to be waiting >= 1 clk to know we are edge based, we have 6+4+6 per half cycle, or ~2.5MHz ceiling (and that is just to capture into width)
- is that correct ? and does the wait have a granularity of 1 for waiting ?
What is the Max rate for POSEDGE and NEGEDGE counting ? an expected 40MHz ?
WAITs have a granularity of one clock.
Somewhat less, per Kuroneko's observation: http://forums.parallax.com/showthread.php?110325-FYI-single-wire-high-speed-serial-link-(updated-20110514)&p=914151&viewfull=1#post914151
-Phil
What is the Max rate for POSEDGE and NEGEDGE counting ? an expected 40MHz ?
Somewhat less, per Kuroneko's observation: http://forums.parallax.com/showthread.php?110325-FYI-single-wire-high-speed-serial-link-(updated-20110514)&p=914151&viewfull=1#post914151
[/QUOTE]
That's a slightly different question. I was asking about using POSEDGE / NEGEDGE to make a HW divider, whilst the linked issue seems to be a silicon blindspot in wait
waitpeq mask, mask ' may block indefinitely
where it fails to see a fast-toggling pin, - so is it really testing the pin every cycle ? - or is there some noise filter at work ?
What frequency conditions does this start to behave at ?
We know for a fact that there are delays (@80MHz), my assumption is about signal degradation.
There is also the possibility that the 40MHz clock transitions are delayed so far that they happen the moment the signal is sampled. Even then I'd expect the occasional transition to be caught which would be enough to register as POSEDGE event. But I'm not an expert in this area. It just irks me.
40MHz is the expected limit of a edge detect.
Did you try a different prop as the generator, so it is Async, and is it ok at /3 /4 /5 etc ?
rdlong delay, #0 ' clkfreq mov cnt, cnt add cnt, #9 waitcnt cnt, delay [COLOR="orange"]mov phsb, #0[/COLOR] waitcnt cnt, #0 [COLOR="orange"]mov phsb, phsb[/COLOR] wrlong phsb, par ' reportASYNC will have to wait until tomorrow.I tried your program from post #5 above, with different results. First on a demo board, it did not hang on pin p16, but it did hang on pins 0,1,8,12,13,14,15. All worked fine at 5MHz+PLLx8, 40 MHz, so that points to a clock delay/degradation or a pin slew rate issue. Thinking there might be something about the demo board with all the stuff attached to the pins, I tried the same program on a virgin proto board, nothing connected to the pins. (modified the program to emit a letter on the p30 debug port in place of the led display, still with the coginit(4...)). In that case, it hung on pins 2, 12, 13, 14, 15 but worked okay on all others. Worked okay on all pins at 40MHz.
Also at 80MHz, a slight shift of the bang-out frequency away from 40MHz avoids the lockup. For example, frqa = $8000_0010 or frqa = $7fff_ff00 do work (meaning not hang in the wait), presumably because the phase shifts to a favorable position relative to sampling. Of course, you'd rather that it not miss any counts at all.
A followup: If a capacitor (22pF) is tied from the affected pin to Vss avoids the lockup. Also, if the Prop is sitting there hung, hitting it with component cooler causes it to continue.
Classic PIN edge detect is a min of two flipflops, and the decode is simple
(There can (should) be clock domain sampling FF's upstream of this, but they act as a pipeline)
and the 'maths limit' for this, is 40MHz (SysCLK/2), but in the real world, there is transit time and skew, and sampling apertures.
The transit time will be likely more than one clock (which is why location and temperature matter), and skew means you can actually precisely miss a pulse that is under 12.500ns
It also shows why WAIT can freeze, as the state never makes it to the outer cases with a 40MHz signal.
If you allow skew, then the fMAX comes down from the theory limit of 40, to
5ns Skew => 1/(25n+5n) = 33.3333MHz (@ 50% duty cycle, so not from a NCO )
6ns Skew => 1/(25n+6n) = 32.258MHz (@ 50% duty cycle, so not from a NCO )
/3 from a NCO will be 2Hi+1Lo, or 1Hi+2Lo ? - and so it can still hit that skew issue, as there is a (12.5ns -skew), pulse being sampled. I'd expect a 1Lo to skew more favorably.
The lockup exit may take some time, as here you are waiting for the NCO to produce an output OTHER than 12.5ns toggle, which it will eventually do for numbers other than $8000 0000.
The average frequency moves, but the edge-phase does not.
As expected, because the signal flight times are more than one SysCLK, if you can move in phase so you DO sample 1010, then it will work ok.
Because of the pain?
Anyway, isn't that all a bit academic? POSEDGE & Co don't have usable outputs so the idea of a h/w divider doesn't really fly, right?
I posted an object that is supposed to generate counted bursts of pulses at up to 40MHz (when clkfreq=80MHz). http://obex.parallax.com/objects/776/ With the demo for that object there is a monitor that uses POSDET to count the number of pulses that are produced in the burst, a number from 1 up to whatever would make 26 seconds worth. The number counted should agree exactly with the number entered (at the PST terminal screen). For example, you can enter a frequency of 40MHz and 33333333 pulses, and the POSDET count should then tell you that it counted 33333333 pulses. Empirically, it is accurate even at 40MHz. Above 40MHz, as expected, it misses counts. For example, with 40.000001 MHz, it reports 33333331 pulses, and with 40.000100 it reports 33333166 pulses. (A test I just ran) It can't be expected to work there. Still, I am surprised it works as well as it does, sampling states only 12.5ns in duration, given the aforementioned fuzzy transitions.
I've also tried it at clkfreq=100MHz, using one of Bill Henning's (Mikronauts.com) 6.25 MHz crystals. The story at 100MHz is more complicated, and it does seem to depend on which cog/which pin. I'll try to make sense of those results.
Incidentally, the terminal object in your OBEX package has a length of 0.
Thanks for the heads up on the absent terminal object. There seems to be an issue with the way bst does archives. I had to rename the file without spaces to get it into the archive. It is the stock Parallax Serial Terminal. Will update.
And it varies from prop to prop while keeping the general idea.
To pick on cog#4 a little more, the output for clkfreq=80MHz, i/o at 40MHz, and asking for 333333 pulses out, gives the following trace: For this unloaded protoboard, it is the same for all combinations of pins and cogs.
At clkfreq=100MHz, i/o at 40MHz, again 333333 pulses, the trace is not so good... The number counted is incorrect for pins 0 to 15, but correct for pins 16 to 28. For all cogs, it is the low numbered pins that are incorrect, and high numbered pins are okay. At 100MHz, all cogs/pins test okay at i/o frequency of 25MHz, but some fail at 26MHz.
I probably have a bug in the logic--would appreciate if someone could check it. {For some reason, I cannot scan cog#1? -- Oh, forgot, PST is running there}
I thought at first glance POSEDGE could drive to PinB, but I think that is not a divided drive, but merely a PinA mirror drive.
Underlines my point, about trivial oversights in silicon... (sigh)
Is that 40MHz from another prop, or dividing by 2.5 ?
25MHz will always divide 'nicely' by 2Hi/2Lo, but 26 will sometimes insert a 1Hi+2Lo or 2Hi+1Lo on the NCO output.
It is those single-widths that fall foul of skew and sampling and Pin Bandwidth effects.
ie 26MHz from a signal generator, would be OK.
Anytime your round trip transit times exceed a clock period, you are moving into more conditional territory, on narrow pulses.
Once the pulse is longer than a critical capture width (H & L ), then you may delay an edge by sampling, but should not lose counts.
Some strange results there. Are those crystal derived on both chips ?
Are they typical spreads, or do results always belong to the set of three ?
I guess you could reverse the boards/swap the code, to flip the crystal error, and so factor that out ?
Marko, I see what you mean, the bias of low pins vs high pins would come from the fact that the signal is emitted from cog#0. Also, that kind of result would mainly be important when using the i/o pins to signal from one cog to another.
Asynchronous is another matter, interesting results and a telling analysis. The percent low, ~0.154% holds true for the other test frequencies too, with a similar relatively small variation from test to test, all low by approximately the same %.
How to interpret it? Should a transition happen to fall at exactly the point in time when the input is sampled, the result could fall either way. Not a point really, but a window. Suppose the input is random or at least sufficiently uncorrelated to the sampling frequency, in such a way that there is a probability of 0.00154 that an input transition hits that window of uncertainty. Would that bias the result to a lower count by that percentage?
A 20MHz symmetrical waveform from one Prop might be different enough from the 20MHz sampling of another Prop to qualify as uncorrelated.
The standard practice in crossing clock domains is to use single-D Flipflips, and then aperture uncertainties, can only ever 'delay by one clock'. NOT miss an edge entirely.
What you DO need to avoid, is driving multiple bits, as then aperture uncertainties can bite.
With a single pin being sampled, it is hard to see how they can use anything other than a chain of FF - typical would be 1-2 for sample/domain cross, and 2 for the State decode above. (two pre ff is normal, to avoid metastable issues affecting Tsu )
With the low frequencies having 'plenty of slack', there is no sampling excuse to drop ~15500 counts.
Of course, another variable in this mix, is the PLL in the Prop. It may be the frequencies really are off by 0.15%, and unstable within 20ppm ?
Perhaps a 3rd opinion, in the form of a reciprocal frequency counter is needed ? I would suspect a real freq error has crept in somewhere.
Apologies for any confusion.
I concur with the picture that any potential problems with missing a count should only arise at clkfreq/4 and above.
There was an early thread about how the flip-flops are arranged at the inputs. In particular Chip chimed in on the issue of metastability with respect to forking paths (carefully designed to avoid that). I'm just re-reading that now.