Hal,
Currently I see the following clock domains. ( See updated architecture
block diagram including the dotted lines showing the split in clock
domains: http://athome.kaashoek.com/time-nuts/architecture_3.png )
1: Inside the MCU everything is clocked with the 200MHz clock from the
CPU. All incoming signals that interact with timers are resampled with
this 200MHz. also the output clock is within this MCU clock domain. Not
sure if this can be stated but the VC-TCXO seems to be in the same clock
domain as the 200MHz clock is derived from the 10MHz clock via a PLL
without resampling.
2: Each input has as clock domain its own clock. The Enable Timestamp
function is a flip-flop clocked by the input clock.
3: The last clock domain is PPS from the GPS .
Does this make sense?
The resampling on the input channels happens at the same 200MHz as used
by the time counter. The total delay between inputs and counters and
triggering of capturing seems to be constant. To validate this I
generated two 10MHz signals with variable phase difference and, using
interpolation over 5e4 measurements, measured the phase difference every
second. The measured/calculated phase difference is, apart from pulling
when the two phases edges come close, consistent with the generated
phase difference, constant and much more accurate than the 5ns time
resolution. The calculated standard deviation is consistent with the
increase in accuracy as predicted by the amount of measurements used in
the interpolation. This hopefully indicates there are no instabilities
in the time relationship over the clock domains. Is this a correct
reasoning or am I missing something?
Any advice on how to validate such an architecture is most welcome.
Erik.
On 17-7-2022 7:26, Hal Murray via time-nuts wrote:
Metastability is one of my hot buttons. When I see a sketch like that, I
expect to see dotted lines splitting clock domains.
Your MCU will probably have an extra flipflop on the input channels for a
synchronizer. That adds delay which may or may not be significant.
Hal,
Currently I see the following clock domains. ( See updated architecture
block diagram including the dotted lines showing the split in clock
domains: http://athome.kaashoek.com/time-nuts/architecture_3.png )
1: Inside the MCU everything is clocked with the 200MHz clock from the
CPU. All incoming signals that interact with timers are resampled with
this 200MHz. also the output clock is within this MCU clock domain. Not
sure if this can be stated but the VC-TCXO seems to be in the same clock
domain as the 200MHz clock is derived from the 10MHz clock via a PLL
without resampling.
2: Each input has as clock domain its own clock. The Enable Timestamp
function is a flip-flop clocked by the input clock.
3: The last clock domain is PPS from the GPS .
Does this make sense?
The resampling on the input channels happens at the same 200MHz as used
by the time counter. The total delay between inputs and counters and
triggering of capturing seems to be constant. To validate this I
generated two 10MHz signals with variable phase difference and, using
interpolation over 5e4 measurements, measured the phase difference every
second. The measured/calculated phase difference is, apart from pulling
when the two phases edges come close, consistent with the generated
phase difference, constant and much more accurate than the 5ns time
resolution. The calculated standard deviation is consistent with the
increase in accuracy as predicted by the amount of measurements used in
the interpolation. This hopefully indicates there are no instabilities
in the time relationship over the clock domains. Is this a correct
reasoning or am I missing something?
Any advice on how to validate such an architecture is most welcome.
Erik.
On 17-7-2022 7:26, Hal Murray via time-nuts wrote:
> Erik Kaashoek said:
>> An architecture level overview can be found here:
>> http://athome.kaashoek.com/time-nuts/Architecture_2.JPG
> Metastability is one of my hot buttons. When I see a sketch like that, I
> expect to see dotted lines splitting clock domains.
>
> Your MCU will probably have an extra flipflop on the input channels for a
> synchronizer. That adds delay which may or may not be significant.
>
>
