Define internal signal as a base clock?

Be careful with "Cut Timing Path" for clocks in the Classic Timing Analyzer. There was a case in the past where the behavior was changed. Neither the old nor the new behavior would be obvious if you didn't already know about it. I think it might have had to do with the same signal being handled as both a clock and a data signal, but I don't remember the details. It also seems like the case I knew about involved wildcards.

--- Quote Start ---

Regarding the multiplexer issue raised by Brad, I think, this shouldn't cause any trouble as long as clk_mux_setting is constant, although the multiplexer is decomposed to multiple cascaded LUT levels. My argument is, that for a given combination of clk_mux_setting the logic is such, that the multiplexer output doesn't depend on any other clock input than the selected one. But I'm not absolutely sure of this conclusion, so if you can give an example suggesting this might be different, I would think anew.

--- Quote End ---

A LUT output will not glitch for a single input toggling. If, for example, you use a LUT to gate a clock with clock_out = clock_in AND enable, then clock_out will not glitch while enable is inactive even though clock_in continues to toggle.

A LUT output might glitch if more than one input is toggling. Even if the second toggling input switches between two locations in the look-up-table RAM that have the same value for the output (making the input a logical don't-care), the output can glitch as the toggling input switches between those two locations. This means that even a 2:1 mux implemented in a single LUT can have glitches on the output while the mux select is held constant. This isn't a problem for a mux in a synchronous data path (the glitches settle out in time if there is positive slack for clock setup), but it is a risk for clocks and asynchronous signals (like an asynchronous reset). I do not know whether this has changed for the most recent device families, but it is the case for at least most device families before the newest ones.

This potential for glitches, besides the cautions in the other thread to which I referred AndyC_772, is yet another reason to be very careful when you have logic in a clock path. A lack of hardware failures in the field to date does not mean that there will not be a problem in the future. The odds of failure might be very low, but designs that require high reliability must be careful about the things I posted in the other thread. The already fielded units might have sufficiently covered the voltage and temperature contributions to the PVT variation. The process portion of variation could be different though every time product is shipped using devices from a new production lot.