[time-nuts] Re: Microcontroller based frequency divider

[Simon Merrett]

Dear all who responded – thank you for everything I’m learning from you.

Gerhard,  thanks for flagging your alternative implementation, especially the gateware. I’m not yet acquainted with FPGAs but it is still useful to read and generous of you to share.

Tom, thanks. I do hope that you are correct about the possibility of many microcontrollers being able to do this. There are some 24 bit TCC/TC peripherals which appear to link to the event systems on some of the cheaper Arm Cortex M0+ microcontrollers. And possibly a 16 bit and 8 bit pair of counters could be chained in an 8 bit microcontroller. I wonder about offset/lag but get a good impression that the event system can act asynchronously to the CPU and peripheral clocks on the new ATtinies. They also have very basic configurable logic cells that may come in handy. The external reset/synch feature of picDIV is extremely attractive for my imagined use, so I hope to implement something similar. Your jitter measurements are very impressive – I would be keen to get whatever I come up with broadly verified to a couple of orders of magnitude greater than that!

Bruce, that is a good point about internal crosstalk. So it may be better to configure the input reference clock as the microcontroller clock, rather than rely on the microcontroller running  a separate internal CPU clock as well as receiving the reference signal to be divided into a timer/counter peripheral. At least something to watch out for as I go along.

Marek, that is pretty amazing. I am not au fait with the pico yet but I do have one in my parts drawer for just such an occasion as this! If my initial attempts with a more familiar chip are not promising, I think your implementation will be the very next thing I look at in detail

Gilles – any information that you are using AVR is helpful, even if you didn’t formally verify. The single instruction cycle is useful for me, as I anticipate wanting to add a delay line to offset and then pulse after e.g. 10e6 – 1 + delay so I can correct for delays.

Florian, you make perfect sense and I was completely scrabbling around for anything that might hint at all the latent specs we wish were in datasheets but aren’t! I think the proof will be in the pudding, not the datasheet. So now I need to go and try some things out in the real world.

Yours,

Simon

________________________________
From: usenet at teply.info <usenet at teply.info>
Sent: Sunday, May 1, 2022 1:34:56 PM
To: time-nuts at lists.febo.com <time-nuts at lists.febo.com>
Subject: [time-nuts] Re: Microcontroller based frequency divider

On 30.04.22 23:22, Simon Merrett wrote:
> I know they were unavailable from one of my usual distributors when I checked last week. I also prefer surface mount parts and that narrows the availability somewhat but isn't a red line for me.
>
> I'm very open to the idea that the PIC12F was a one-off in terms of the timing performance. But I have also heard that modern silicon processes could yield better results, based on informed conjecture. I am more familiar with eg the newer ATtiny series of chips and the Microchip Cortex M series parts. I realise that datasheet figures are often just an envelope of performance and they don't mention jitter but the PIC12F states something like a 10 ns gpio rise time and a recent ATtiny specs something like 1.5 ns. For the simpler (AVR, not Arm) parts, maybe there is a whole bunch which would be suitable. I'm happy to build some but I can't (yet) do the testing to see if they are viable. If there are other contenders I'd be happy to look at them too.
>
Please do not mistake the rise time quoted on the datasheet for anything
related to timing accuracy. While it is true that rise time poses an
upper limit on the maximum frequency a given parts I/O circuitry can
support, it does not by itself impose an equivalent granularity and
therefore does not limit the timing relationship between two signals.

A pretty drastic example for illustration: Imagine a lowpass filter as
circuit (it doesn't matter here how that is constructed, could be RC,
LC, active or passive, you name it). For the sake of argument, let's
assume the cutoff frequency of that lowpass is 10 Hz (again, fully
arbitrary number). When we apply a rectangular pulse to the input, we
will see a low-pass filtered version of that on the output some time
later. The exact shape of the output and delay between input and output
will depend on actual implementation, but nevertheless due to the 10 Hz
cutoff of the filter the output edge will be pretty slowly rising when
compared to our rectangular pulse at the input. One problem we see here
is that the limited slew rate of the output edge creates some
uncertainty on the timing depending on where we actually measure the
delay. Where exactly do we place the border where the output signal
changes from logic low to logic high? For digital logic circuitry, this
is actually not well defined as they usually only specify that inputs
below voltage V_l are considered low, and inputs above V_h are
considered high, and there is a gap between V_l and V_h where behaviour
is undefined. Actual behaviour is mostly deterministic for any given
physical sample, but can vary between several nominally identical parts.

But back to the example. Let's assume we have a somewhat ideal case such
that part-to-pat variation does not exist or at least doesn't play a
role (because we only have one sample to look at). And we also fixed the
decision point to, say, halfway between logic high and logic low.

If we put in our edge at t_0, we will observe the output to cross our
decision point at t_0+t_d. No matter what we do, the output transition
will always be t_d after the input transition. If we change t_0 by 1 fs,
the output will also rise 1 fs later, maintaining our t_d time
difference between input and output transition. The same goes for
changing t_d: As long as it is constant, it does not influence timing
accuracy as constants always can be taken into account if they are known.

One problem remains however: Rise time by itself is not well defined,
and depending on manufacturer preferences and/or type of circuit can
vary considerably for various reasons.
For one, it depends on the actual load connected to the output. Often it
is spec'ed for capacitive loads of 50 pF, or 15 pF for higher speed
circuits. Also, it might be spec'ed for a 10% to 90% transition, or a
20% to 80% transition, or even a 30% to 70% transition. In some cases
it's not even specified which load and transition corners have been
used. In the end, it depends on how much current an output can supply to
charge the capacitance of its load. Now, if we consider a 30-70
transition and a 15 pF load, or a 10-90 transition on a 50 pF load, the
1.5ns and 10 ns you mentioned could well have been on the very same I/O
circuit. Simplifying the I/O to a constant current source and a
capacitor, and taking into account that a 10-90 transition spans twice
the voltage range as a 30-70 transition while a 15 pF capacitor charges
about three times as fast as a 50 pF cap on the same current, this could
already explain the difference between the two parts you mentioned.

On top of that, rise times usually are spec'ed only as maximum, while
actual parts can and mostly will be faster than that by a considerable
amount. How much faster remains to be seen.

One thing that also needs to be kept in mind: The example given above
only applies to time invariant systems. Very strictly speaking, sampled
systems however are not time invariant with respect to their
input-signal-edge to output-signal-edge delay unless the time difference
between input signal edge and clock edge is constant.

Hope this clears things up a bit and doesn't cause extra confusion...

Best regards,
Florian
_______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send an email to time-nuts-leave at lists.febo.com
To unsubscribe, go to and follow the instructions there.