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.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
The reference clock may be lost when the other board providing it is reset (such as during reconfiguration).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).
Not on clock changes, but on the clock..which provides no such guidelines on clock changes.
The reference clock may be lost when the other board providing it is reset (such as during reconfiguration).
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...).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?
Not sure how duplicating the system would help...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 ...
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.This would be considered normal behaviour in most applications. How much downtime do you expect from the other board?
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.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.
In this case there's a requirement that all boards be frequency locked to each other. Otherwise things would definitely be a lot simpler.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.
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?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.
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?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.
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.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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?