Switching two (synchronous) clocks with variable phase difference, without glitching or period loss

I have two clocks which are relatively synchronous (ie. the frequencies
are exactly the same because the originate from the same master clock),
but one of the clocks is shifted in phase, and this phase shift is
dynamically variable and may be up to one whole period.

I need to switch between these two clocks, but without losing rising
edges. From my experiments with BUFGMUXs, I appear to be losing a
rising edge (post PAR timing simulation).

I believe Peter's circuit in his Six Easy Pieces may also cause an edge
to be lost. Peter writes "Any clock-switching starts when the
originally selected clock goes Low, and the Output Clock then stays Low
until the newly selected clock has first gone Low and then High again."

I realize that asynchronous clock multiplexing has been covered many
times in the group, but I simply can't find a good solution to my
specific problem.

Peter.

PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
>
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
>
> I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> to be lost. Peter writes "Any clock-switching starts when the
> originally selected clock goes Low, and the Output Clock then stays Low
> until the newly selected clock has first gone Low and then High again."
>
> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.
>
> Peter.

A very simplistic method to capture phase is the old type 1 phase
detector; feed the clocks to a XOR - the output pulse is proportional
to the phase between the clocks. This assumes you have something that
can measure it.

Alternatively, should you need to know the edge phase for a rising
edge, use a 2 input AND gate, for a falling edge a 2-input NOR (to
garner a high for each condition).

(My preferred fix for synchronised but unknown or unknowable phase
between the clocks for data is a FIFO, with the output delayed by 1 or
2 clocks. As your phase could be a whole period, I'd use 2 clocks.)

I know you said you need to switch between the two clocks - so I'd
think about using phase detection as noted above. There are very simple
and effective phase detectors available (see the type 2 as well).

Cheers

PeteS

PeteS wrote:
> PeterC wrote:
> > I have two clocks which are relatively synchronous (ie. the frequencies
> > are exactly the same because the originate from the same master clock),
> > but one of the clocks is shifted in phase, and this phase shift is
> > dynamically variable and may be up to one whole period.
> >
> > I need to switch between these two clocks, but without losing rising
> > edges. From my experiments with BUFGMUXs, I appear to be losing a
> > rising edge (post PAR timing simulation).
> >
> > I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> > to be lost. Peter writes "Any clock-switching starts when the
> > originally selected clock goes Low, and the Output Clock then stays Low
> > until the newly selected clock has first gone Low and then High again."
> >
> > I realize that asynchronous clock multiplexing has been covered many
> > times in the group, but I simply can't find a good solution to my
> > specific problem.
> >
> > Peter.
>
> A very simplistic method to capture phase is the old type 1 phase
> detector; feed the clocks to a XOR - the output pulse is proportional
> to the phase between the clocks. This assumes you have something that
> can measure it.
>
> Alternatively, should you need to know the edge phase for a rising
> edge, use a 2 input AND gate, for a falling edge a 2-input NOR (to
> garner a high for each condition).
>
> (My preferred fix for synchronised but unknown or unknowable phase
> between the clocks for data is a FIFO, with the output delayed by 1 or
> 2 clocks. As your phase could be a whole period, I'd use 2 clocks.)
>
> I know you said you need to switch between the two clocks - so I'd
> think about using phase detection as noted above. There are very simple
> and effective phase detectors available (see the type 2 as well).
>
> Cheers
>
> PeteS

Further to this, a trick I used many years ago (using discrete parts
too!) was to ensure that the phase between the clocks was between 90
and 270. To do this you need at least a 4x clock somewhere to measure
the actual phase difference.

If the phase pulse is too short or too long, simply invert the
currently inactive clock.

Cheers

PeteS

"PeterC" <peter@geckoaudio.com> wrote in message 
news:1155193653.437411.172220@i3g2000cwc.googlegroups.com...
>
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
>

Given that, the two should be treated as if they are completely 
asynchronous.
.
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
>

You may have a very good reason, but why can you not afford to lose an edge? 
When circumstances allow you should always try to switch clocks at a time 
when there is 'nothing going on' in either clock domain.  Are you sure that 
in your application that the clock switching could really be occurring at a 
time when stuff is still happening in both clock domains that you don't want 
to miss?

It might very well be that you really can't afford to lose an edge in your 
application, but it's a key question that affects how 'simple' or 
'complicated' the design solution is going to be so it's worth double 
checking.

> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.
>
What resources are at your disposal?  The traditional approach to moving 
from one clock domain to another would be simply through the use of dual 
clock FIFOs.  Are there any dual clock memories primitives and spare logic 
available for use?  If so, then plop down an lpm_fifo_dc (I think that's the 
correct name for the LPM dual clock FIFO) on each clock path and select 
between the two on the output side, holding the unselected path in reset.

KJ 

Peter,
the way you describe your problem, there is (and there can be) no
solution, if you switch asynchronously between two unknown clocks.
You will lose an edge, since you cannot use edges that are very close
to each other.
Assume the two rising edges are 50 ps apart. Are they two edges or one?
How's about 1 ns, etc.?
You must be willing to lose an edge, and the"six easy pices" circuit is
your solution.
Cheers
Peter Alfke, Xilinx
==================
PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
>
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
>
> I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> to be lost. Peter writes "Any clock-switching starts when the
> originally selected clock goes Low, and the Output Clock then stays Low
> until the newly selected clock has first gone Low and then High again."
>
> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.
> 
> Peter.

PeterC,

The best I was able to do was to switch using a plain 2:1 multiplexer.

But I followed this with a 'clean up PLL'.  That way, there was no
possibility of ever having a bad clock cycle at the output of the PLL.
If the input to the PLL just goes to a simple XOR phase detector, the
worst that can happen is you build out one clock cycle, either + or -,
over time, sometimes (not always) when you switch.

Since this was used throughout the synchronization and timing systems we
were building, the equipment met Bellcore requirements as a sync source.
 The requirement was that if you had to slip or swallow a clock cycle,
it happened over a long enough period of time that no bit errors were
created in the entire central office, anywhere.

Eventually, if you accumulate an entire frame of 193 bits (old T1 design
made all switch buffers no more than two frames, and many were one
frame) you would drop an entire frame from every line in the central
office (they didn't like that at all).  Since the switch of clocks was
asynchronous, and you could slip or swallow an entire clock period if
the phases were exactly wrong; on average, you did not gain nor lose any
bits in the buffers (all was well).

I do not think there is any way possible to do what you are asking, as
all of my competition did no better, either (and many did worse).

Austin

Aside:  the 193 bit buffer is also related to the total allowed delay
across a switch:  three 125 uS periods (three frames of 193 bits at T1).
 At faster rates, with larger frames, the buffers are obviously allowed
to be larger than 193 bits.

PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
> 
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
> 
> I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> to be lost. Peter writes "Any clock-switching starts when the
> originally selected clock goes Low, and the Output Clock then stays Low
> until the newly selected clock has first gone Low and then High again."
> 
> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.
> 
> Peter.
> 

Peter Alfke wrote:
> Peter,
> the way you describe your problem, there is (and there can be) no
> solution, if you switch asynchronously between two unknown clocks.
> You will lose an edge, since you cannot use edges that are very close
> to each other.
> Assume the two rising edges are 50 ps apart. Are they two edges or one?
> How's about 1 ns, etc.?
> You must be willing to lose an edge, and the"six easy pices" circuit is
> your solution.
> Cheers
> Peter Alfke, Xilinx
> ==================
> PeterC wrote:
> > I have two clocks which are relatively synchronous (ie. the frequencies
> > are exactly the same because the originate from the same master clock),
> > but one of the clocks is shifted in phase, and this phase shift is
> > dynamically variable and may be up to one whole period.
> >
> > I need to switch between these two clocks, but without losing rising
> > edges. From my experiments with BUFGMUXs, I appear to be losing a
> > rising edge (post PAR timing simulation).
> >
> > I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> > to be lost. Peter writes "Any clock-switching starts when the
> > originally selected clock goes Low, and the Output Clock then stays Low
> > until the newly selected clock has first gone Low and then High again."
> >
> > I realize that asynchronous clock multiplexing has been covered many
> > times in the group, but I simply can't find a good solution to my
> > specific problem.
> >
> > Peter.

Hi Peter

As much as I dislike disagreeing with the renowned Peter Afke, one can
switch between two asynchronous clocks (in this case as the frequencies
are locked but the phase differs, and can change).

I once designed a hitless switch (in telecom, for DS3) to switch
between two source synchronous bit streams, with a phase asynchronicity
attributable to path delay which was variable, that did not miss a bit
during switching between space diversity receivers (hence hitless :)

That's important in DS3, of course, as missing a bit has a major hit on
framing, so frame relock is then necessary, which was deemed
unacceptable.

It takes a little work but can be done. In that case, I conditioned
both the clocks _and_ the data stream (which could have a significant
bit position offset), which may be overkill here.
Without knowing more about the specifics of PeterC's requirements,
(both for clock rates and phase rate of change apart from overall
structure) it's hard to be specific. I will also mention I used
discrete and analog techniques (ECL for the logic) - this was in the
days before really fast VLSI (or even really fast LSI for that matter,
excepting ECL), but the same techniques could be used simply transposed
completely into the digital domain.

Maybe I'll chew over it over the next couple of days, run up some code
over the weekend and post it (warning : I prefer Verilog ;)

Maybe :)

Cheers

PeteS

Wow, three Peters in various stages of disagreement...
I suppose it depends on the basic assumptions.
In "6 easy...", I assumed a worst case, where the switching is
asynchronous, and the two clocks have no known phase of frequency
relationship.
In today's posting the two frequencies are identical, but the phase
relationship is unknown. Let's assume the decision to switch is
synchronous with the presently used clock. Then you have to make sure
that the to-be-acquired rising clock edge is at least a clock period
later (otherwise I can get in timing trouble). That assumption
inherently loses one clock transition (except in the extreme case when
both phases are aligned.
If you change the rules, and acept a shorter clock cycle during the
switch-over, things are different, but you now must put a limit on it,
otherwise you get two clock edges that are very close (and how close is
too close ?)
That's why I wrote my skeptical remarks.
Back to the Peters
Peter Alfke.
=====================
PeteS wrote:
> Peter Alfke wrote:
> > Peter,
> > the way you describe your problem, there is (and there can be) no
> > solution, if you switch asynchronously between two unknown clocks.
> > You will lose an edge, since you cannot use edges that are very close
> > to each other.
> > Assume the two rising edges are 50 ps apart. Are they two edges or one?
> > How's about 1 ns, etc.?
> > You must be willing to lose an edge, and the"six easy pices" circuit is
> > your solution.
> > Cheers
> > Peter Alfke, Xilinx
> > ==================
> > PeterC wrote:
> > > I have two clocks which are relatively synchronous (ie. the frequencies
> > > are exactly the same because the originate from the same master clock),
> > > but one of the clocks is shifted in phase, and this phase shift is
> > > dynamically variable and may be up to one whole period.
> > >
> > > I need to switch between these two clocks, but without losing rising
> > > edges. From my experiments with BUFGMUXs, I appear to be losing a
> > > rising edge (post PAR timing simulation).
> > >
> > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> > > to be lost. Peter writes "Any clock-switching starts when the
> > > originally selected clock goes Low, and the Output Clock then stays Low
> > > until the newly selected clock has first gone Low and then High again."
> > >
> > > I realize that asynchronous clock multiplexing has been covered many
> > > times in the group, but I simply can't find a good solution to my
> > > specific problem.
> > >
> > > Peter.
>
> Hi Peter
>
> As much as I dislike disagreeing with the renowned Peter Afke, one can
> switch between two asynchronous clocks (in this case as the frequencies
> are locked but the phase differs, and can change).
>
> I once designed a hitless switch (in telecom, for DS3) to switch
> between two source synchronous bit streams, with a phase asynchronicity
> attributable to path delay which was variable, that did not miss a bit
> during switching between space diversity receivers (hence hitless :)
>
> That's important in DS3, of course, as missing a bit has a major hit on
> framing, so frame relock is then necessary, which was deemed
> unacceptable.
>
> It takes a little work but can be done. In that case, I conditioned
> both the clocks _and_ the data stream (which could have a significant
> bit position offset), which may be overkill here.
> Without knowing more about the specifics of PeterC's requirements,
> (both for clock rates and phase rate of change apart from overall
> structure) it's hard to be specific. I will also mention I used
> discrete and analog techniques (ECL for the logic) - this was in the
> days before really fast VLSI (or even really fast LSI for that matter,
> excepting ECL), but the same techniques could be used simply transposed
> completely into the digital domain.
>
> Maybe I'll chew over it over the next couple of days, run up some code
> over the weekend and post it (warning : I prefer Verilog ;)
> 
> Maybe :)
> 
> Cheers
> 
> PeteS

PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the frequencies
> are exactly the same because the originate from the same master clock),
> but one of the clocks is shifted in phase, and this phase shift is
> dynamically variable and may be up to one whole period.
>
> I need to switch between these two clocks, but without losing rising
> edges. From my experiments with BUFGMUXs, I appear to be losing a
> rising edge (post PAR timing simulation).
>
> I believe Peter's circuit in his Six Easy Pieces may also cause an edge
> to be lost. Peter writes "Any clock-switching starts when the
> originally selected clock goes Low, and the Output Clock then stays Low
> until the newly selected clock has first gone Low and then High again."
>
> I realize that asynchronous clock multiplexing has been covered many
> times in the group, but I simply can't find a good solution to my
> specific problem.

How "short" a clock period can you tolerate from the clock switching
hardware?

How long can you wait before a missing clock is stuffed back in?

PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the
 > frequencies are exactly the same because the originate from
 > the same master clock), but one of the clocks is shifted in
 > phase, and this phase shift is dynamically variable and may
 > be up to one whole period.
 >
 > I need to switch between these two clocks, but without losing
 > rising edges.

In that case, it's impossible, because two edges from the two
clocks can be arbitrarily close together.

Like other respondents, I too have done telecom applications
that needed hitless switching between streams that are
frequency-locked but not phase-locked. The answer involves
passing at least one of the clock+data streams through an
elastic buffer in order to realign their phase before trying
to do the switching. A 3-bit elastic buffer will allow just
shy of 2 unit intervals of peak-to-peak wander before causing
a hit.

If this is the sort of thing you need, I can dig up an
implementation for such a buffer that requires about 7
flip-flops and a handful of gates.

-- Dave Tweed