Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Switching to a backup clock when main clock fails

Status
Not open for further replies.
M

mtwieg

Advanced Member level 6
Joined
Jan 20, 2011
Messages
3,835
Helped
1,310
Reputation
2,626
Reaction score
1,405
Trophy points
1,393
Activity points
29,372
In my design I want to distribute an externally provided clock, but switch to a backup on-board clock (both are 10MHz) if the external clock fails. I'd like the transition to be smooth (no missing or runt pulses), so I presume there must be a PLL involved. But I want my output frequency to be the same as the references.

I searched around for single-chip solutions and found that the ICS581-02 does exactly what I need, but unfortunately it's obsolete. Haven't found any other options, which is surprising since I assumed this would be a pretty common scenario.

My inputs/outputs are currently 3.3V single ended, but lvds would be doable as well.

Anyone have any recommendations?
 

Hi,

For 10MHz I see no need for LVDS.

For such a system you need to involve the datasheet of the connected devices.
They define how the system (switch over) needs to be designed.

Parameters are: min and max low level time, min and max high level time, phase, frequency step...

Klaus
 

Is this a safety critical system? I have never seen such a setup for consumer devices (where you usually just ship it back for a repair).
 

KlausST said:
For such a system you need to involve the datasheet of the connected devices.
They define how the system (switch over) needs to be designed.

Parameters are: min and max low level time, min and max high level time, phase, frequency step...

Klaus
Click to expand...
The main device the clock is being fed to is an Intel FPGA, which provides no such guidelines on clock changes. Intel's official advice is to use their internal PLLs which feature automatic clock switching for exactly my scenario. However, they do not actually function properly. It's a known bug I'm trying to work around.

TrickyDicky said:
Is this a safety critical system? I have never seen such a setup for consumer devices (where you usually just ship it back for a repair).
Click to expand...
The reference clock may be lost when the other board providing it is reset (such as during reconfiguration).
 
Last edited:

Hi
mtwieg said:
which provides no such guidelines on clock changes.
Click to expand...
Not on clock changes, but on the clock..

Usually every clock input has a specification.
No device can operate on clocks with a duty cycle close to zero or close to 100%.
If you switch from one clock to the other there is no predictable timing unless you care fore this beforehand.

I doubt that such a circuit brings much benefit...
How to detect that one input clock fails?
There are several possible "fails" for a clock:
* wrong LOW level
* wrong HIGH level
* wrong duty cycle
* wrong rise/fall time
* wrong frequency
* too jittery
Is your switchover circuit able to detect (all) those errors?
And if it detects ... how much time is allowed to switch over?
And does it switch back...if the clock is considered good?

I may be wrong, but I guess that a duplicated system...including duplicated FPGA could be the more useful.

Also: A clock source usually is a relatively simple system, but a circuit for detecting wrong clock and clean switchover may be much more complicated. A high chance to fail ...

Klaus
 

mtwieg said:
The reference clock may be lost when the other board providing it is reset (such as during reconfiguration).
Click to expand...

This would be considered normal behaviour in most applications. How much downtime do you expect from the other board?
 

I remember to have used the Intel clock switching feature in a project, there's in a fact a strange behaviour of the clock presence detector which needs to be surpassed. But I'm not sure if the function is suited for switching on the fly without possibly generating out of spec clock signal. The FPGA VCO is simply too wide band. I would rather think about a voltage controlled crystal oscillator module locked to the master clock.
 

    M

    mtwieg

    Points: 2
    Helpful Answer Positive Rating
KlausST said:
How to detect that one input clock fails?
There are several possible "fails" for a clock:
* wrong LOW level
* wrong HIGH level
* wrong duty cycle
* wrong rise/fall time
* wrong frequency
* too jittery
Is your switchover circuit able to detect (all) those errors?
And if it detects ... how much time is allowed to switch over?
And does it switch back...if the clock is considered good?
Click to expand...
Detecting the loss of the external master clock is pretty simple in this case. It just shuts off abruptly, with no change in duty cycle or frequency. Detecting master clock coming back is more difficult. The synthesizer output for the master clock is masked up until it has locked, which means the slave board doesn't see a tracking PLL output. But during reconfiguration, the master clock does toggle a couple of times. Have to make sure the clock detector on this mux isn't too sensitive (which is a the problem in the Intel solution...).

I may be wrong, but I guess that a duplicated system...including duplicated FPGA could be the more useful.
Click to expand...
Not sure how duplicating the system would help...

Also: A clock source usually is a relatively simple system, but a circuit for detecting wrong clock and clean switchover may be much more complicated. A high chance to fail ...
Click to expand...
TrickyDicky said:
This would be considered normal behaviour in most applications. How much downtime do you expect from the other board?
Click to expand...
Currently when the master board is reconfigured and the master clock disappears momentarily, all slave boards reset (triggered by their own PLLs losing lock). I don't think I have to explain why this is undesirable. Would be preferable to have a gentler means of sequencing operations rather than killing the clock without warning. But I can't even attempt to do that unless I first figure out a way to ride out the loss of the clock.
 

Most boards I have seen/used will always use a local clock internally, with the data on the interfaces brought into the local clock ASAP. That way if an interface goes down the whole system wont die.
 

FvM said:
I remember to have used the Intel clock switching feature in a project, there's in a fact a strange behaviour of the clock presence detector which needs to be surpassed. But I'm not sure if the function is suited for switching on the fly without possibly generating out of spec clock signal. The FPGA VCO is simply too wide band. I would rather think about a voltage controlled crystal oscillator module locked to the master clock.
Click to expand...
A vcxo is definitely an idea worth considering, thanks! I see lots of options for vcxos at 10MHz, but not sure how to approach selecting a PFD/PLL. Any suggestions? I'm hoping for something that doesn't need to be configured with a serial interface to start working.

edit: The ADF4007 is sooo close to what I need, but doesn't allow for a 1:1 frequency ratio.

--- Updated ---

TrickyDicky said:
Most boards I have seen/used will always use a local clock internally, with the data on the interfaces brought into the local clock ASAP. That way if an interface goes down the whole system wont die.
Click to expand...
In this case there's a requirement that all boards be frequency locked to each other. Otherwise things would definitely be a lot simpler.
 
Last edited:

I have in the past (10+ years ago) done something like this where the clock was selected via a mux using the "signal present" signal on a fibre link. If the signal was present it would switch to the recovered clock. If this went down, it went to the on board clock. At the time the chip had no clock muxes, so the clocks were input via 2 clock pins, logic muxed, output onto a pin and back in via a clock pin (via a wire link as this was all done to fix a glitch on the fact the clocks were a few ppm different). This was very stable at 27Mhz and worked just fine.
In this case though, there were no PLLs involved and the recovered clock/crystal clock were used directly.
 

    M

    mtwieg

    Points: 2
    Helpful Answer Positive Rating
A cheap solution without additional hardware can be build utilizing the Intel PLL dynamic phase shift feature. By continuously shifting the phase of the M divider, the VCO and all output clocks of a PLL can track an external signal with up to several 100 ppm frequency offset.
 

    M

    mtwieg

    Points: 2
    Helpful Answer Positive Rating
FvM said:
A cheap solution without additional hardware can be build utilizing the Intel PLL dynamic phase shift feature. By continuously shifting the phase of the M divider, the VCO and all output clocks of a PLL can track an external signal with up to several 100 ppm frequency offset.
Click to expand...
Trying to picture exactly how this would be executed... the local clock is fed to an ALTPLL, whose output is then compared with the master clock with some sort of PFD, then the output of that PFD would dynamically adjust the ALTPLL phase?

I'm assuming the PFD and feedback would run off a clock much higher than either external clock (or the ALTPLL output and master clock would be divided down before the PFD). Might be something worth trying in parallel with a hardware solution.
--- Updated ---

TrickyDicky said:
I have in the past (10+ years ago) done something like this where the clock was selected via a mux using the "signal present" signal on a fibre link. If the signal was present it would switch to the recovered clock. If this went down, it went to the on board clock. At the time the chip had no clock muxes, so the clocks were input via 2 clock pins, logic muxed, output onto a pin and back in via a clock pin (via a wire link as this was all done to fix a glitch on the fact the clocks were a few ppm different). This was very stable at 27Mhz and worked just fine.
In this case though, there were no PLLs involved and the recovered clock/crystal clock were used directly.
Click to expand...
I'm betting that the clock recovery for the fibre link was implemented in such a way that the recovered clock doesn't die the same instant that the fibre signal does. So the recovered clock persists until the loss of signal is detected and the clock switch occurs?
 
Last edited:

The clock came from the fibre IC. The clock muxing was all asynchronous logic, so it wouldnt have mattered if the recovered clock died before the lock signal went down.
 

mtwieg said:
I'm assuming the PFD and feedback would run off a clock much higher than either external clock (or the ALTPLL output and master clock would be divided down before the PFD). Might be something worth trying in parallel with a hardware solution.
Click to expand...
The dynamic phase shift unit is running at max. 100 MHz, a phase step is executed every 4 or 5 clock cycles. The effort to setup a PLL depends on the acceptable phase jitter. A very simple solution that is nevertheless working well if you can tolerate some extra jitter is to perform a pulse-by-pulse phase compare of internal and external clock and trigger the phase shift up or down according to the result. Smoother operation can be achieved with a PI loop controlling the phase shift through a sigma-delta algorithm.
 

Just to give an update, I've decided to go the route of using a VCXO+PLL to lock to the master clock. For the PLL, I found that there are fast versions of the old CD4046 chips which are still cheap and simple as dirt, but work well above 10MHz. The 74HCT9046A in particular looks nice since it has a true charge pump output.
 

I would say that the most "seamless" handover would
be to feed the incoming clock to a PLL and narrowband
VCXO, and feed that output to the clock "client". Find a
way to disable the charge pump and "lock" the Vtune
if the ref clock leaves. But if you use a fairly narrow tune
range VCXO of appropriate frequency any error ought
to be small.

A digital PLL and NCXO might be even more "lockable"
as there are no "drift factors". But I think these are more
rare, custom even.
 

Yes, that's basically what I'm doing. For my application, a frequency error of +/-100ppm doesn't matter when the master clock is absent. So I can let the VCXO free run anywhere within it's pull range.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top