Xilinx: Prohibit propagation of timing constraint through a mux

Using a mux to select between two different clocks can cause you a lot of trouble, because you must avoid output glitches. I published an absolutely safe solution as the final item in "Six eeasy pieces" as TechXclusives (search for it on the Xilinx website.) That design is guaranteed to switch glitchfree between two free-running clocks, no matter when or how you activate the Select input. Peter Alfke, Xilinx Applications

Karel-

I have fought with this also. My conclusion is that clock-oriented timing constraints, including CLOCK_SIGNAL constraint, are basically worthless for fabric signals. If there is any app note that truly shows how to use them on non-clock signals, I'd sure like to see it. Once you cause XST to "jump off the clock net" as Austin puts it, I don't know what you do to get back on it.

If your clocks are truly free-running, and you never have to switch away from a dead clock, then simply use a BUFGMUX, as has been suggested many times on the group. You will be good.

If one clock is free-running, but one may stop, then you might still be able to use a BUFGMUX by doing this:

-Use I0 input on the BUFGMUX for the always-running clock

-ensure the clock that could stop (on I1 input) always stops at a low-level

-use a state-machine based on another, independent clock to measure the output of the BUFGMUX and determine when to switch

Following these guidelines, a BUFGMUX appears to work without getting stuck. There may be some Xilinx evidence to support this, if you look carefully at behavior of a BUFGCE, which is a BUFGMUX with I1 tied to GND and sel line used as CE (enable). With a BUFGCE, the CE line can be toggled any time. I am in the process of testing the above use of a BUFGMUX billions of times to verify.

I would like to take this opportunity to ask that Peter and Austin to let us know exactly what is the circuitry in the BUFGMUX. It's too important a feature to be guessing how it behaves when its inputs are not always running. If it does not exactly match Peter's Six Easy Pieces circuit, which I suspect it does not based on what I've heard on this group, then we should know the modifications. If this info is covered under NDA that should be Ok as people who need to know should have no trouble to go that route.

-Jeff

Hello Peter,

I think I shouldn't care about the glitches: the datapath is in reset whe a clock switching occurs. The reset is deactivated once the switch ha changed state. My biggest problem are the constraints; how should I constrain th datapath in the three different clock domains?

Thanks and best regards, Karel Deprez

You can try to play with the PRIORITY keyword: e.g.

# the lower the PRIORITY number, the higher the priority TIMESPEC TS_In1 = PERIOD In1 60 MHz PRIORITY 0; TIMESPEC TS_In2 = PERIOD In2 50 MHz PRIORITY 1;

HTH, Jim (jimwu88 at yahoo dot com)