BUFGMUX glitch-free behavior

[radar_macgyver]

I'm using a BUFGMUX on a Spartan-3A design to switch between two clocks. One of these comes from off-board (LVDS) on a connector. The other is from a crystal oscillator. I can write to a control register within the FPGA to control the select line of the BUFGMUX between the two. However, the 'glitch free' switching nature of the BUFGMUX makes this scheme not work when the off-board LVDS clock is not present - the BUFGMUX never switches state. If I introduce a small glitch into the off-board connector (touching it with a scope probe is enough), the glitch pulse causes the BUFGMUX to switch state over to the crystal oscillator and everything works fine.

Here's how I'm instantiating the BUFGMUX:

Code: [Select]

io_clk_mux : BUFGMUX
port map (I0 => EXT_CLK_B, I1 => clk_100_ibuf, S => io_clock_select, O => io_clk_b);

Is there a way to defeat this behavior? I tried to make the default value of io_clock_select to be '1' to select the oscillator clock, but it doesn't seem to help. Due to layout constraints, I'm forced to use the specific clock pins on my board, and therefore I can't swap the BUFGMUX input pins I0 and I1 (Map complains about violating dedicated clock routing within the device). The S3 user guide states that the 'S' pin polarity can be selected, but doesn't mention any attributes or other means to do so.

The Spartan-6 FPGAs have a CLK_SEL_TYPE attribute that can be set to 'ASYNC' to disable the glitch-free behavior - any way to do so on Spartan-3?

[Someone]

BUFGMUX_1 ? not sure if its actually a different primitive or just a convenience wrapper.
many people forget how restrictive the older generation FPGAs were, almost anywhere to anywhere clocking is sure nice to have on the newer parts.

[hamster_nz]

Pass the external signal though a PLL or MMCM and use the LOCKED signal to MUX the clock??

Not sure how the PLL or MMCM act when lock is locked, but you might get a few extra ticks out of it, enough to switch clocks.

(Don't forget that you will need to reset the PLL/MMCM to regain lock when signal returns).

[hamster_nz]

Found it in UG331:

Using the LOCKED Signal
To operate properly, the DCM requires a stable, monotonic clock input. Once locked, the
DCM tolerates clock period variations up to the value specified in the specific FPGA data
sheet. If the input clock stays within the specified limits, then the output clocks always are
valid when the LOCKED output is High. However, it is possible for the clock to stray well
outside the limits, for the LOCKED output to stay High, and for the DCM outputs to be
invalid. It is good design practice to monitor both LOCKED and the STATUS signals.
Monitoring STATUS[1] is recommended as this will indicate when CLKIN has stopped
(moved outside the acceptable CLKIN tolerances). STATUS[1] will go High after one
missed CLKIN cycle. However, the DCM might not lose LOCKED unless CLKIN is
stopped for more than 100 ms. STATUS[1] is not a sticky bit; it will go Low once CLKIN has
returned. For the most robust indicator of the status of your DCM's output clock,
monitoring both the LOCKED and STATUS[1] bits is recommended.


So a short while after STATUS[1] is goes high, switch clocks before it unlocks.

[radar_macgyver]

@Someone
BUFGMUX_1 is the same as BUFGMUX, except that when you give it a switching command (by toggling the S input), the output idles high until it sees a transition on both I0 and I1 (BUFGMUX idles low).

@hamster_nz:
That sounds like it may work, but I can see two potential snags: first, the super-restrictive Spartan-3 clocking restrictions may not let me route the clock into a DCM input while also routing the DCM output to the BUFGMUX. Second, how does a DCM behave when it has never seen an external clock at all? Does its output toggle while it's acquiring lock? A PLL/MMCM will do this, but I'm not sure a DCM will. I will give it a try though.