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

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

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

Given that, the two should be treated as if they are completely asynchronous. .

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.

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

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:

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

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?

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

Thank you to all who replied.

Without going into details of the application, I have enough new insight to go on. I did omit some details in my OP relating to the phase difference rate change as well as the range, but the postings have certainly helped me think differently about the issue.

Big thanks to Pete S for his courageous stance on Peter A's first reply!