[time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop

Javier Serrano javier.serrano.pareja at gmail.com
Wed Oct 15 09:27:41 EDT 2014

Hi Simon, I am the initiator and leader of the White Rabbit project,
which in the context of these discussions is more a disqualifier than
anything, since I do very little technical work these days,
unfortunately. Please forgive me if I have misunderstood what you are
trying to do. Some tentative answers below:

On Wed, Oct 15, 2014 at 1:58 PM, Simon Marsh <subscriptions at burble.com> wrote:
> On 15/10/2014 10:29, Bruce Griffiths wrote:
>> The use of a synchroniser loses no information apart from fine details
>> about the metastability response of the sampling flipflop. With a 10Hz
>> offset and a 10MHz clock the sampling resolution is 100fs with the phase
>> difference between the flipflop clock and data input transitions changing
>> monotonically by 100fs between successive active clock transitions. Phase
>> noise/jitter between the flipflop and data input transitions will typically
>> result in a burst of state transitions at the synchroniser output rather
>> than a single transition when the active clock transition and a data
>> transition coincide..
> Right, this is my understanding of what the white rabbit articles refers to
> as glitching and is why I know I have something wrong when I see no noise at
> all.

Do you have a precise idea of what the offset in frequency is between
your DUT(s) and the slightly-offset oscillator? If that offset is too
big compared with the jitter of your clock signals and your
flip-flops, that would explain why you see no glitches. Locking to
your DUT frequency is a good way to make sure you control the offset.
Small frequency offsets are typically implemented by multiplying by
(N-1)/N with N big enough. There is a trick (from NIST I think) for
achieving high N by cascading two PLLs which multiply by M-1 and M+1
respectively. The effective multiplication factor is then (M^2 - 1).
Making M^2=N and inserting the divide-by-N in between the multipliers
gives you the global (N-1)/N. We don't use this trick, but it can be
handy in some circumstances. BTW, does anybody have a pointer to the
original reference for it?

> What I'm less sure about is what I should expect to see as the clock/data
> phase steps through the unstable region of the sampling flip flop's
> response. Whilst the synchroniser will ensure I get an output of some sort
> at each cycle, its going to take many cycles @100fs to step through before
> the sampling flip flop is stable again. Is this likely to appear as
> (random?) state transitions at the synchroniser output ? perhaps this region
> just gets lost in the mush of clock jitter ?

You should indeed use a synchronizer made of a chain of FFs of length
at least two. You should see the typical glitch pattern after the
first FF and also after the second, i.e. what you should see in an
oscilloscope should pretty much look the same for both FF outputs.
Only in the very infrequent cases where you hit the metastability
window of the first FF there should be a difference between what you
see after the first FF and after the second one (except of course for
the fixed one cycle latency). Notice I am abusing the word 'glitch'.
These are pulses of at least one clock cycle duration.

The current implementation used in WR was developed by Tomasz
Wlostowski in the frame of his MSc thesis, following the ideas of
Pablo Alvarez which Bruce pointed to earlier. As you can see in
Tomasz's dissertation [1], there was not a lot of investigation on
optimal strategies for DDTMD noise. The precision at the time was
deemed more than adequate. It is very timely that you bring up this
subject now, because I hope to start looking at ways to optimize phase
noise in WR in the coming months, and noise coming from the DDMTD
phase detector is definitely something I want to look at. I will be
very interested in your ideas and findings regarding optimal
strategies for the de-glitcher.



[1] http://www.ohwr.org/documents/80

More information about the time-nuts mailing list