BUFGMUX glitch-free behavior - Page 1
Forum section: electronics / general

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: August 12, 2022, 09:18:18 pm
content: 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:io_clk_mux : BUFGMUXport 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?

author: Someone
author_rank: Super Contributor
timestamp: August 13, 2022, 12:34:19 am
content: 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,almostanywhere to anywhere clocking is sure nice to have on the newer parts.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 13, 2022, 01:23:36 am
content: 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).

author: hamster_nz
author_rank: Super Contributor
timestamp: August 13, 2022, 01:38:19 am
content: Found it in UG331:Using the LOCKED SignalTo operate properly, the DCM requires a stable, monotonic clock input. Once locked, theDCM tolerates clock period variations up to the value specified in the specific FPGA datasheet. If the input clock stays within the specified limits, then the output clocks always arevalid when the LOCKED output is High. However, it is possible for the clock to stray welloutside the limits, for the LOCKED output to stay High, and for the DCM outputs to beinvalid. It is good design practice to monitor both LOCKED and the STATUS signals.Monitoring STATUS is recommended as this will indicate when CLKIN has stopped(moved outside the acceptable CLKIN tolerances). STATUS will go High after onemissed CLKIN cycle. However, the DCM might not lose LOCKED unless CLKIN isstopped for more than 100 ms. STATUS is not a sticky bit; it will go Low once CLKIN hasreturned. For the most robust indicator of the status of your DCM's output clock,monitoring both the LOCKED and STATUS bits is recommended.So a short while after STATUS is goes high, switch clocks before it unlocks.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: August 13, 2022, 04:13:38 am
content: @SomeoneBUFGMUX_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.